BB2-1728: Proof of concept for C4DIC implementation

[jimmyfagan]

JIRA Ticket:
BB2-1728

What Does This PR Do?

This PR does three main things, two of which are temporary for the Proof of Concept, and only one of which would be necessary in a permanent implementation. The two temporary changes:

• Add support for returning hardcoded C4DIC resources. These are kept in a separate folder as json files that can be returned by a helper function. To enable this, in each desired function (read Patient, search Patient, read Coverage, search Coverage) there is a variable that can be set to enable the returning of those hardcoded resources.
• Point to the test instance of BFD where as of today the C4DIC profile is currently supported. This largely eliminates the need for the hardcoded C4DIC resources, but if the BFD team removes the C4DIC profile from their test instance, the hardcoded resources can be used as a fallback.

The change that would be needed permanently is related to the handling of the _profile parameter, since that will be required for API users to specify if they want Coverage resources corresponding to C4BB or C4DIC.

Corresponding changes to the Python sample client can be found in this draft PR.

What Should Reviewers Watch For?

If you're reviewing this PR, please check that the changes can be understood easily enough even without recent knowledge of the conversations around C4DIC.

Validation

This was continually validated through POC demos in the last few months of 2024.

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations