Implement routing of messages and observation pruning based on condition

[arnejduranovic]

User Story

As a receiver of test results potentially containing multiple conditions, I want the messages I receive to only have the conditions I care about, so that I can have an easier time processing the messages

Description/Use Case

In order to be able to route messages based on condition, we first need to be able to stamp various observations in a message with the condition(s) they represent. This was done as part of #12275. This ticket will build on top of that and add support for:

1. Routing a message based on the conditions that are contained within it and each receiver's condition settings
2. Pruning observations that are linked to conditions NOT in the receiver's condition settings

The tentative design for this is documented in the code to condition mapping design note under the section titled Filtering for condition.

Note, the design suggests where and how to implement this feature. This design should be used as a guide and NOT as a hard requirement. We should implement routing and pruning in a way that is most maintainable. This may mean refactoring current functionality.

Risks/Impacts/Considerations

The design note mentions the following:

During the routing step the results of the condition filter are evaluated and for observations which pass the filter a reference to that observation is added to the FHIR bundle endpoint resource. During the Translate step any observations not referenced in the endpoint resource of the FHIR bundle will not be added to the outgoing report to the receiver. This will include both observations where a mapping could not be found as well as observations representing a reportable condition that is not of interest to the receiver.

The decision to add an observation to the endpoint resource to indicate that is passes a filter is based on existing functionality - which will be removed in #12224. We will need to think through a new solution for this part and update the design note.

Dev Notes

Acceptance Criteria

• [ ] ReportStream has the ability to route observations based on their mapped conditions
• [ ] ReportStream has the ability to prune observations from a message to adhere to a receiver's selected conditions
• [ ] pruning tested
  • [ ] verified we remove any orphaned resources after removing observations
• [ ] routing tested
  • [ ] a message where all observations are to be filtered out does not get sent to a receiver

[Andrey-Glazkv]

Hey team! Please add your planning poker estimate with Zenhub @arnejduranovic @jalbinson @JessicaWNava @jimmyfagan @thetaurean @JFU-NAVA-PBC