LG-309 Allow dynamic service provider updates in production

[stevegsa]

Why: So we can make changes to existing SP's or add new ones at anytime and not have it coupled to the release process.

How: Treat our SP configurations and assets as data. Allow urls for public certs and logos and whitelist the static site or our github repo as a CMS. Create a remote settings table that caches the current version of agencies.yml and service_providers.yml seeder files and update the seeders to conditionally use the remote content. Provide a rake task that allows us to update, delete, list, and view the current remote settings.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• 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.

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

[monfresh]

Is the idea that we would SSH into a prod server and run rake db:seed every time we want to update the SP settings?

Given that we already have the capability of dynamically updating the ServiceProviders table via the Dashboard app and our api/service_provider endpoint, why is that not a viable solution?

[stevegsa]

Correct we would run the seeder every time we wanted to update the sp settings. @brodygov and Joel would not approve using the dashboard with prod for security reasons and time constraints. However, I outlined in a separate document that we could work towards that goal even if it's in the far future. The changes here are an incremental first step towards that goal which involves freeing the assets (images and certs) from ec2. The dashboard can update certs now but can't upload logos (which are not stored in the db). You can only change the name of the logo which must exist on the server. Logically you wouldn't want to store the images in the db and we were already aiming to get the assets on to CloudFront.

[monfresh]

LGTM. Comments can be addressed later.

[monfresh]

Can we also add a spec for the rake task please?