BFD-2720: Fix bug with samhsa matcher class cast in RDA logic

[lsmitchell]

JIRA Ticket:
BFD-2720

User Story or Bug Summary:

After a recent adjustment to the RDA code to use dependency injection, one of the side effects was a mis-cast on some logic that changed as a result of the transformer injection. This fixes that.

---

What Does This PR Do?

Root cause of this issue was injecting a single transformer based on the resource type into the resource provider. The samhsa matcher REQUIRES the resource to be transformed into a claim, so when resources were passed into the samhsa matcher of a claimResponse resource provider, it used the claimResponse transformer, attempted to cast it to a claim after, and blew up.

This fixes that by moving the samhsa determination logic into the samhsa matcher, and injects the appropriate transformers into THAT class instead of needing the resourceProvider to always have a claim transformer handy.

• Moved hasNoSamhsaData from the Abstract resource provider into the samhsa matcher class
• Inject the claim transformers needed for hasNoSamhsaData into R4ClaimSamhsaMatcher (was already an injected component, but previously had no dependencies)
• Add E2E test to make sure with excludeSamhsa=true the claimResponse endpoint does not blow up
• Add unit tests to ensure hasNoSamhsaData works with claim and claimResponse resources in its new home
• Fix the couple spots where we had instantiated the samhsa matcher to accomadate its new constructor

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

• Verify all PR security questions and checklists have been completed and addressed.

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 you must supply a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence here: N/A

  • Does this PR add any new software dependencies?
    • Yes
    • No
  • Does this PR modify or invalidate any of our security controls?
    • Yes
    • No
  • Does this PR store or transmit data that was not stored or transmitted before?
    • Yes
    • No

• If the answer to any of the questions below is Yes, then please add @StewGoin 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
    • No

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following prerequisite changes have been fully deployed:

• N/A

Submitter Checklist

I have gone through and verified that...:

• I have named this PR and branch so they are automatically linked to the (most) relevant Jira issue. Ie: BFD-123: Adds foo
• 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.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• The data dictionary has been updated with any field mapping changes, if any were made.
• 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. DC GEO, BB2, 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.

[mackec1]

LGTM; will follow-up on your comment 'original sledgehammer approach of throwing every transformer into the provider' since that is what I am doing in EOB provider(s).