Add controller/view/xlations/specs for recovery flow reboot

[el-mapache]

Why: We are changing around our accout recovery flow to better match
the existing experience

Linked issue is pretty large, this is a subset of the changes being made to the account recovery flow. Currently, this only adds the new reactivate_account_controller, routes, specs, and view. The user will still be redirected to the existing reactivate_account screen at /account/reactivate

Screenshot:

Designs are still in progress and thus don't match the comps exactly. Updates will be made in a future PR as soon as these are finalized.

[zachmargolis]

1. should this get a leading slash for consistency?
2. to keep these alphabetized by path, should we move these new ones down 2 lines?

[el-mapache]

yeah, I thought about moving them down, but it felt weird since logically startis going to happen first. Our convention is more about alphabetizing, I'll change it

[zachmargolis]

seems weird to me to split across two lines like this, should we use the > syntax? ditto for the key below

explanation: >
  When you created your account ....

[el-mapache]

I can add the > signs, but both of the strings still need a line break to fit within the 100 character limit, right?

[zachmargolis]

yeah, definitely, but the > tells it to ignore newlines inside the strings 😁

[el-mapache]

ok! Do I still need the quotes to escape the : at the end of the string? Or is that going to reintroduce a newline character. Is there a better way to escape?

[zachmargolis]

As long as it's indented consistently the : should be fine

explanation: >
  blah blah blah: blah
  more text goes here indented the same level
  blah: this is fine too

[zachmargolis]

GH's highlighting got that wrong, but I confirmed with the Ruby YAML parser:

irb(main):002:0> YAML.load <<-STR
irb(main):003:0" explanation: >
irb(main):004:0"   blah blah blah: blah
irb(main):005:0"   more text goes here indented the same level
irb(main):006:0"   blah: should be fine
irb(main):007:0" STR
=> {"explanation"=>"blah blah blah: blah more text goes here indented the same level blah: should be fine\n"}

[el-mapache]

Cool, my syntax highlighter was freaking out, so I didn't try it out 😬

[zachmargolis]

code climate is highlighting this as untested, can we add a scenario for visiting without the correct profile?

[el-mapache]

what do you think the cleanest way to test this is? Stub out a user and the password_reset_profile method?

[zachmargolis]

have a spec that signs in to the controller with a user that has no profiles?

[zachmargolis]

Ok so we should definitely try to use as much "real" code as possible and minimize stubbing of specific filters and methods like this.

I would remove these 3 stubs and do:

let(:user) { build(:user, profiles: profiles) }
let(:profiles) { [] }
before { stub_sign_in(user) }

And ditto for the spec below.

Then we can override the let(:profiles) with an array of profile objects to match the various scenarios we want to test. (it might have to be a create(:user ... to make sure they get written to the DB, but same idea

[el-mapache]

@zachmargolis updated, with a 0.1% increase in code coverage 😸

[zachmargolis]

LGTM! Awesome, and thanks for adding the spec! 🚀

[el-mapache]

Of course, thanks for the spec writing tips!