chore: RpcPublisher and RpcConsumer classes

[mackenzie-grimes-noaa]

Linear Issue

IDSSE-1142

Changes

• Create RpcPublisher
  • Rpc class with more specific name. We will delete Rpc after all usages in IDSSe services have been migrated
  • Fix minor bug where Rpc.send_request() defined its own, hard-coded message properties (application/json, for example). Now caller can pass the request message's BasicProperties
• Create RpcConsumer class
  • Opposite of RpcPublisher, listens for Rpc requests, triggers some on_message() function you give it to form a response, then structures the response correctly for Rpc reply

Explanation

Previously we had custom code in DAS that structured and published all its RPC responses in the way that Rpc expects. We'd rather have logic for both ends of the RPC in the same place, and we could theoretically use RPC in another service.

[paulhamer-noaa]

Looks ok as far as I can see. The RabbitMqMessage class could be extended to check for the corr_id sometime in the future I guess? Geary was very keen on making sure that every message could be tracked to the originator of the message using this. Perhaps a backlog task?

[mackenzie-grimes-noaa]

The RabbitMqMessage class could be extended to check for the corr_id sometime in the future I guess?

Good point. I'm leaving it up to the caller of RpcPublisher and RpcConsumer that all the messages they pass have properties.correlation_id set right--they pass in a RabbitMqMessage which is a body and BasicProperties, so it's up to them to pack the right properties in there.

Would be a good thing to enforce in the future, I'll add a small task.