ACapi: discovery: can stale selectors be updated on success

[wesrowe]

Description

User story

As a Cartography team member, I want to see if stale MHV selectors – i.e., ones based on MPI rather than the ACapi call – can be updated by a successful ACapi call, so that Veteran experiences that use those selectors can benefit from the ACapi automatically.

Notes

• Kevin documented some of the staleness details in a canvas (look right below the tracker tables)
• Joe Niquette of Identity team added a feature in which the AC-API is called on sign-in.

Possible tasks:

• Determine if Niquette's API response is stored in state
  • If so, is it using user.profile.mhvAccountState?
• If Niquette isn't using user.profile.mhvAccountState, then our ac-api logic should be selecting for his state instead of user.profile.mhvAccountState
• Determine if there is a reducer for user.profile.mhvAccountState or whatever state Niquette's response is saved to
• Make use of said reducer when we make our call to the AC-API

Acceptance criteria

• The Cartography team has a more perfect (documented) understanding of the source of the FE's source of truth for the user's MHV account status
• The mhv landing page updates the same state that the sign-in logic does.
• alert-standardization docs reflect the correct selector for all tool teams
• QA review
• A11y review

[kjsuarez]

Related conversation

TL;DR
The api call at login does update user.profile.mhvAccountState so all this ticket needs to wory about is finding/implementing a reducer (bullet 2 of AC)