[LG-487] Email based Suggesting scoped by agency

[jgsmith-usds]

Why:
Because user messaging is done based on SPs, we want to make
sure we restrict our suggestion of piv/cac use for folks to
those interacting with select SPs and email domains.

How:
Switch from an OR to an AND. Moves some code around.

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.

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.

[jmhooper]

So the change here is that now if I want to use a PIV/CAC to sign into GSA, I have to use my GSA email? (assuming here we live in a world where GSA SPs support PIV/CAC)

[jgsmith-usds]

For now. It's a way to indicate that you're part of an organization for which we believe we have the signing certs in-hand to validate your piv/cac cert. Once we add multiple-email support, we'll look at all of the emails on your account to determine this, so you can still use a non-government email address as your main account email, but add your government one to unlock this feature.

We're scoping it so you have to have a supported email address and be interacting with a partner agency/SP so that we can better manage the roll out messaging. The prior PR didn't add the SP scope, so we would have made it available regardless of how the person is interacting with login.gov.

It could be that a non-GSA agency/SP wants to support piv/cac, so if we supported GSA pivs, you'd be able to use a GSA piv with an account that had a GSA email for a non-GSA SP.

We aren't making the list of supported email domains dependent on the SP. We're just keeping a list of supported email domains, and a list of SPs that want to make piv/cac available for any supported email domain.

For this PR, we're working with agencies. There's a future ticket to scope by SP rather than agency.

[jmhooper]

Got it