Onboarding: Non-happy path

[avivash]

In the current version of the fission-server, we won't receive any errors related to duplicate emails until after the user has completed these three steps:

1. Submitted their email to the server
2. Submitted their pin to the server
3. Submitted their username to the server

Which means only on the third screen, after the username has been sent to the server, will we know the user needs to enter a different email address:

To account for this error path in the UI, we will have to make a fairly convoluted user flow. For now, we're opting to focus on the existing happy path, rather than complicating the happy path to support the error path.

@depatchedmode and I will discuss this with the server team to determine an ETA for username-first logins. Perhaps there are other solutions on the server that can be implemented sooner, as well. If the server work isn't too out, it may make sense to keep the same UI we have and direct users to a support forum in the meantime. Also, until the server work is completed, we can simply send users back to the email entry screen when the error occurs and include some sort of error message akin to:

"It looks like that email is taken. Please enter a different email address."

[avivash]

Related server issue: fission-codes/fission-server#194

[depatchedmode]

@avivash and I discussed this and as he mentions above, we think the best course of action right now is to leave the happy-path as is and life with a clumsy error state.

We could combine all the fields into a single submission, but that would mean the happy-path would be a poor experience, and the error state wouldn't necessarily feel more clear.

So, for now: kick the user back to the email input with the error: "{email} is already registered. You can link this device from any device on which that account is currently connected. If you need help, please post in the Beta Forum."

Moving forward, we'd like to:

1. Have the email and account name endpoints be separate, with appropriately scoped error responses.
2. Investigate auto-delegation from the authorized email, if an account already exists. Does it fit our current security model to authorize the new device if the user has proven ownership of the account?
3. Remove the email as the unique account identifier bottle neck. We need it for communication, and it could be one of many auth / recovery factors. But there may be value in a single email being an auth factor for multiple accounts.