Add the notion of an "invalid email" state to an account

[ckarlof]

Currently when a user's email bounces hard, we delete the account. This is reasonable, but the user will start to get some confusing errors on the client side as a side effect.

I propose that in reaction to hard email bounces we instead put the account in an "invalid email" state, and change some our APIs to account for this disabled state:

• Change /account/status to return { exists: <bool>, state: <state> }, where if exists is true, then state describes what state it is in.
• Change the /account/create, /account/login, /account/destroy, /password/change/start and /password/forgot/send_code to return a 400/107 error indicating a "invalid email" when the user tries to interact with an account in this state. This would signal to clients that they should check /account/status for further clarification. This is not ideal, but it's perhaps the best we can do without introducing new error codes and be backwards compatible with existing client code.
• Accounts in the "invalid" state should return a 400/110 for authenticated calls.
• After some time period (a day? a week or two?) we delete accounts in the "invalid" email state

Gecko code to support /account/status has already landed, and will need to be updated to support this new state. However, these changes should be backwards compatible with the explicit deletion case.

This will also help with #714.

[ckarlof]

Bug for Desktop/B2G support of these changes: https://bugzilla.mozilla.org/show_bug.cgi?id=1011773

[ckarlof]

/cc @ncalexan

[vladikoff]

Got here via triage,

@rfk should we keep this open?

[rfk]

Let's keep it open for now, and revisit it as part of the multi-email work.

[vladikoff]

cc @rfk , should we move it to fxa-features or close?

[rfk]

Closing, I'll pitch this into our features pipeline and we can take a fresh look at it