BB2-4294: Update fhir_ids on token refresh

[bwang-icf]

JIRA Ticket:
BB2-4294

What Does This PR Do?

This PR ensures that both fhir_id_v2 and fhir_id_v3 are populated if null, or updated if the value in the DB is different than what is returned from BFD, on refresh token flow (this already happened on authorization flow).

What Should Reviewers Watch For?

• Do the added/modified unit tests adequately cover this change?
• Do we still update user_mbi and other crosswalk fields as we did before this change was made (specifically looking at mymedicare_cb/models.py)? I tested all of this, but want to make sure it looks good to reviewers.

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

Validation

• Do unit and integration tests all pass?
• Here's the process I did to validate the functionality in addition to adding/modifying tests:
  • Authorize in Postman (did this for v2 and v3 auth/token URLs)
  • Grab that crosswalk record from the database, note the fhir_id_v3 and fhir_id_v2 values
  • Update fhir_id_v3 to null, then click refresh the token via Postman, query that crosswalk record again and make sure fhir_id_v3 is equal to what it was before updating to null
  • Repeat the same process as above for fhir_id_v2, and also update fhir_id_v3/fhir_id_v2 to some other value, then refresh the token and make sure they were set back to the correct value before any updates were done

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

[jadudm]

Do we have a test/want a test that asserts that the result of an update via each method produces the same result? E.g. something that calls one refresh, caches a result/value from the DB, then resets the DB (say, by nulling out the v3 id), calls the other refresh, and then compares the two? Or, because of how we mock things, is that redundant/not meaningful?

[JamesDemeryNava]

By other refresh, do you mean the two ways we now call _get_and_update_user? I can write a test that calls get_and_update_user_from_initial_auth, then we modify some values, then call get_and_update_from_refresh and verify that the values have been updated correctly if we think that would be useful.

I don't think it's absolutely necessary as we have tests for both functions already, but happy to add the test if we want it.