[VI-850] updates SiS session refresher to poll MPI for id theft & death flags

[bramleyjl]

Summary

This PR serves to patch a vulnerability discovered wherein a mobile user who originally authenticated with valid MPI death & id_theft flags had one of those authentication-blocking attributes updated in MPI but was maintaining a session on the VA mobile app. This change makes it so that every time a User model is instantiated via SiS auth it check the MPI profile (Redis cache or MPI API query) for MPI death & id theft flags.

Code changes

• Updates services/sign_in/user_loader::reload_user method to call newly-created User model validate_mpi_profile method.
• The MPI profile is checked for id_theft_flag and deceased_date attributes and failures of those validations results in an MPILockedAccountError error being raised and the authentication action terminating.
• Specs covering these changes to
  • base & mobile module ApplicationController spec
  • UserLoader spec
  • User model spec

Related issue(s)

• https://jira.devops.va.gov/browse/VI-850

Testing done

• New code is covered by unit tests
• Update your user's user's vets-api-mockdata mvi/profile_icn/<icn>.yml to include one of the following:
  1. Deceased Flag - within the <patientPerson> block add the following two attributes
     • <deceasedInd nullFlavor="PINF" value="true"/>
     • <deceasedTime value="19991231"
  2. ID Theft Flag - within the <patient classCode="PAT"> block add the following attribute
     • <confidentialityCode code="ID_THEFT^TRUE"/>
• Authenticate & attempt to access an authenticated route - you should receive a 403 error with the appropriate MPI flag message.

What areas of the site does it impact?

Authenticated routes

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[bosawt]

I wonder if we could put this in UserLoader and run the checks when the user model has to be recreated

[bosawt]

Looks gud, thanks for making those changes

[emilykim13]

Tested with new changes, lgtm with the changes!

[DonMcCaugheyUSDS]

Nice -- thank you!