LG-1399 Spinner for docauth requests

[stevegsa]

Why: So users don't get frustrated and leave or cancel when the uploads take a while on slow internet connections

How: Create a general solution for one spinner per page. Hook in javascript to where we disable submit buttons and unhide a single spinner if it exists upon submit.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the checklists below. These represent the more critical elements
of our code quality guidelines. The rest of the list can be found in
CONTRIBUTING.md

Controllers

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated
  as the first callback.

Database

• Unsafe migrations are implemented over several PRs and over several
  deploys to avoid production errors. The strong_migrations gem
  will warn you about unsafe migrations and has great step-by-step instructions
  for various scenarios.

• Indexes were added if necessary. This article provides a good overview
  of indexes in Rails.

• Verified that the changes don't affect other apps (such as the dashboard)

• When relevant, a rake task is created to populate the necessary DB columns
  in the various environments right before deploying, taking into account the users
  who might not have interacted with this column yet (such as users who have not
  set a password yet)

• Migrations against existing tables have been tested against a copy of the
  production database. See LG-228 Make migrations safer and more resilient #2127 for an example when a migration caused deployment
  issues. In that case, all the migration did was add a new column and an index to
  the Users table, which might seem innocuous.

• When fetching a single record from the database, #take is used instead
  of #first unless there is an #order call on the ActiveRecord relations.
  This prevents ActiveRecord from sorting by primary key which can result in slow
  queries.

Encryption

• The changes are compatible with data that was encrypted with the old code.

Routes

• GET requests are not vulnerable to CSRF attacks (i.e. they don't change
  state or result in destructive behavior).

Session

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

Testing

• Tests added for this feature/bug
• Prefer feature/integration specs over controller specs
• When adding code that reads data, write tests for nil values, empty strings,
  and invalid inputs.

[stevegsa]

Screenshot

[achapm]

We should present a spinner for the "Continue" button since we do not know how long it will take for the API request to complete. However, I thought this story is for "a visual indicator of progress when uploading the state issued ID". Really, we need it in both places. We may want to create a separate story for the "Continue" spinner and get it merged.

[stevegsa]

@achapm I just looked at the title of the story I didn't realize the text said provide visual progress. That is different than a spinner. I've done it before but it's tricky business to get it to be compatible with all browsers. This is a cheap feedback mechanism to show them we are working on it. The upload actually does occur when they click continue. The preview is a browser/javascript hack and not actually the upload.

[achapm]

@stevegsa Thank you for the clarification. John D said that a spinner is fine. I think you nailed it here.

[achapm]

LGTM 👍