Break account creation spec into 2 specs

[jmhooper]

Why: The account creation spec looked like it was really testing
that the handoff to the SP is successful and that the user verifies the
attributes requested by the SP before handoff. This commit breaks that
spec into 2 separate specs to test those things specifically.

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.

[davemcorwin]

I like the idea and there is nothing wrong with splitting them, but they both are still testing the entire flow. I'm just trying to wrap my hands around what belongs where. For example, in sp_handoff, we test the values in the decoded jwt, while this should be tested, it doesn't seem like a feature spec is the correct place. I think these are complicated because there is a ton of detail here, but I don't have a good sense of whether these types of things are tested elsewhere.

[jmhooper]

Yeah, I agree that these are complicated, and are testing a lot of detail, but I think that is warranted in this case. Since the SP handoff is some it's something I think we should focus on making sure we get right. A feature spec allows us to get the closest to the conditions a user will experience.

[jmhooper]

@monfresh: I re-added expectations for the idv columns on the user. Also I found an important case that didn't looks it was covered: what happens when the user comes back after 24 hours. I added a test for that. PTAL

[jmhooper]

This, was totally the wrong PR 😳. Pls ignore

[monfresh]

LGTM