Save HL7 waveform messages to disk

[jeremyestein]

Implements #140

Also:

• make rabbitmq fanout exchange so emap core and waveform-controller can both read the same waveform messages
• documentation and diagrams
• add some more glowroot instrumentation

[github-actions]

PR checklist

Default guide for a PR (if multiple PRs for the work, only keep one version of it and link to it on the other PRs)

• From the UCLH data science desktop, a validation run has been set off
• Check that content that reveals Epic IP (eg. Clarity/Caboodle queries) has not been checked into a public repo.
• load times
  in UCL teams has been populated with the run information
• During the run, glowroot has been checked for any queries which are taking a substantial proportion of the
  total processing time. This can be useful to identify indexes that are required.
• After the run, look for any unexpected errors in the etl_per_message_logging table, the error_search.sql file
  on the shared drive can be used for this \\sharefs6\UCLH6\EMAP\Shared\EmapSqlScripts\devops\error_search.sql.
  Create an issue if you find an unexpected exception and is not related to the changes you've made, otherwise
  fix them!
• After the run, populate the end time in
  load times
• Let Aasiyah know about the completed validation and give her information on the changes and where to start
  with the validation
• Check validation report and give any feedback to Aasiyah if there are any changes needed on her side,
  iterate on getting the validation to match at least 99% (validation and emap code).

[skeating]

Looks sensible to me, but another more technical eye might be good

[thompson318]

Looks generally good to me. Documentation and puml to svg is very nice. I don't feel experienced enough with java to comment much on that side, but it does seem to work.
One question on the queue fanning. My understanding now is that waveform-export should be consumed by the waveform-controller and that waveform-emap could potentially be comsumed by emap but at the moment is not? Should we be able to turn off one queue in configuration if we decide it's not needed. Presumably these queues have significant overheads to temporarily store the messages?

[jeremyestein]

One question on the queue fanning. My understanding now is that waveform-export should be consumed by the waveform-controller and that waveform-emap could potentially be comsumed by emap but at the moment is not?

It may have not been consuming it for the same reason that the patient locations were out of date. I will check this.

Should we be able to turn off one queue in configuration if we decide it's not needed. Presumably these queues have significant overheads to temporarily store the messages?

You can add and remove queues that are bound to the fanout exchange from within the web admin console, or on the command line as the init script does. If we are to stick with our special Emap instance just for waveform, then it might make sense to delete the waveform_emap queue to reduce resource use in emap-star. Although leaving it running is a form of testing for if/when we want to run live inference on the data in emap-star.

Yes, storing the messages does take up disk space and perhaps there should be more safeguards against filling up the disk (queue size limits?) I made an issue for this #142 .