LG-3787: Create waiting experience for address checking, ID resolution and DocAuth

[aduth]

Why: As a user, I want to know that my data is processing so that I understand that things are progressing as expected.

Screenshots:

Animation:

Message after long wait:

To do:

• Implement in other async steps (Edit: Done in 9ba5029)
• Verify no regressions for existing spinner buttons
• Add spec for spinner-button.html.erb partial, which has increasingly non-trivial logic (Edit: Done in 0d4d3da)
• Add spec for form-steps-wait.js (Edit: Done in 96b774b)

[aduth]

Note to self: Research why accessible-forms.js exists, since in cases like this it prevents screen readers from announcing intended status texts after a submission. At the very least, it could be improved to respect event.defaultPrevented in a submit event.

[zachmargolis]

Just to check my understanding: this PR submits the form on the page as a .fetch request, then checks the HTML response we get back to see if it should advance or not?

Should we consider making a separate API endpoint for polling like we did for the doc auth endpoints?

[aduth]

Just to check my understanding: this PR submits the form on the page as a .fetch request, then checks the HTML response we get back to see if it should advance or not?

Should we consider making a separate API endpoint for polling like we did for the doc auth endpoints?

Correct. It essentially submits the same form in JavaScript, then requests the /verify_wait path to see when it redirects to the next step as an indication of when the user should be navigated along.

The nice thing about it is that it doesn't require any changes to the code that already exists, which we may still want as the progressive enhancement fallback for environments with JavaScript disabled (as long as we care to support no-JS in this flow, that is).

To your question: We could, yes. Per the above, it adds more code that we don't necessarily need. On the other hand, it is a bit unconventional and wasteful to use window.fetch to request full page responses. I'd been looking at whether we could use respond_to to return a simpler response for the fetch request, and/or allow the "wait" step to respond to a HEAD request or similar to what we do with hybrid status checks to return and distinguish between 202 status code (as pending) vs. a redirect.

[aduth]

Should we consider making a separate API endpoint for polling like we did for the doc auth endpoints?

One thought here is to have an endpoint which simply returns the active step of the current user. This would make the logic a bit easier to know whether the user has completed the current step to redirect them along. It could possibly even absorb what we have for /doc_auth/link_sent/poll, where instead of having a dedicated controller for the hybrid completion of the document_capture step, we could simply check to see if the user has advanced past that step.

One complication may be that the CaptureDocStatusController does a bit of extra handling for "failure" cases.

[aduth]

Implement in other async steps

Added to the CAC verification flow in 9ba5029. From the ticket description, it's not clear to me where else we have these sorts of async flows. I don't see any other references in code to this meta_refresh auto-reload-til-complete implementation.

@zachmargolis, @bpdesigns Can you clarify if there are other places this spinner should be implemented?

[aduth]

Should we consider making a separate API endpoint for polling like we did for the doc auth endpoints?

One thought here is to have an endpoint which simply returns the active step of the current user. [...]

On second though, I don't know that we need anything new or custom here? FlowStateMachine#index gives us this information already. We could just send a HEAD request to /verify/doc_auth (or /verify/cac) to know where we should be at in the flow.