BB2-3224: Establish C4DIC feature branch

[jimmyfagan]

JIRA Ticket:
BB2-3224

User Story or Bug Summary:
This PR establishes a feature branch that can be used for POCs, demos, sample app implementation, using C4DIC compliant fhir resources.

What Does This PR Do?

This PR builds off of Adrian's C4DIC POC but with some adjustments based on our current plans moving forward for C4DIC with BFD.

What Should Reviewers Watch For?

If you're reviewing this PR, please test by importing the new Postman collection from this page (look for Blue Button Local Environment (C4DIC)) to verify that the sample C4DIC resources can be retrieved. You will need to generate a new access token that contains the Organization scope to be able to use the Organization endpoint.

Also, note that this is a feature branch which will not be deployed to any real environments in this state. This would be re-reviewed before ever being merged to the master branch.

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then here's a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence: N/A.
  • Does this PR add any new software dependencies? Yes or No.
  • Does this PR modify or invalidate any of our security controls? Yes or No.
  • Does this PR store or transmit data that was not stored or transmitted before? Yes or No.
• If the answer to any of the questions below is Yes, then please add a Security Engineer and ISSO as a reviewer, and note that this PR should not be merged unless/until he also approves it.
  • Do you think this PR requires additional review of its security implications for other reasons? Yes or No.

What Needs to Be Merged and Deployed Before this PR?

N/A

Any Migrations?

None

Submitter Checklist

I have gone through and verified that...:

• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.

[JFU-NAVA-PBC]

LGTM

Played with Postman + Local setup, got C4DIC resources as expected.
Great work on demo a multi profile support API

[sb-benohe]

@jimmyfagan just a note this general PR looks good, However I did notice some failures in the CI on Jenkins from Flake8 for formatting. We might need to add some of these files to the exclusion list

[jimmyfagan]

Good call @sb-benohe I didn't have pre-commit installed on the repo, that's a good topic to bring back to the team probably to address that topic from retro. Pushed fixes, will check CI and then likely merge what I have into the longer-term feature branch.