Rethinking password.reset.flow.open.expects

[stuartpb]

I'm not wild about open, though I guess it has its place, for expire and sessions and for some weirdness around randomize. I'd rather see its children moved to password.reset.flow.change, though some semantics could get tricky (maybe password.reset.flow.change.open.expire?)

I'd like to think about refactoring this away and/or moving it before shipping v0.1.0, taking into account everything that's currently on it. I think password.reset.flow.change.requires would make just as much sense, if not more, as password.reset.flow.change.open.expects (but, pre-flow, it would have been password.reset.change.requires, which would have been weird).

[stuartpb]

Should also be balanced against a prospective opening level (for describing other stuff you have to do to reach a certain point, like just clicking a button), as discussed around #222.

[stuartpb]

For randomize, wouldn't activate or confirm (for an object stating what happens when a password randomize request is confirmed) make more sense? Also, isn't password.reset.randomize.open.result kind of redundant with just password.reset.randomize.response.email.body.contains('password') ? 'change' : 'send'?

[stuartpb]

Ugh, I'd like this to be taken out, but there's more than a little data that depends on it right now, and it's not so easily refactored. (Honestly, the step itself isn't necessarily unsound - just the name/position could be improved.) Moving this to v0.2.0, and this'll just have to ship with v0.1.0.