Add username scheme and hashing support

[walkah]

For AOL apps where email may be optional, provide a function to allow implementations to provide an identity function (auto generated username).

• Depends on Make email optional on registration fission-codes/fission#616

[bgins]

Renamed this issue because we will likely end up with a serialized, internal representation of the username. We will still want the human readable username for user interactions.

[expede]

@bgins & @expede to discuss base64 vs hashing for linking

[avivash]

@bgins would it make sense to do this as part of the fs recovery work since they're both fairly tied together? I'm assuming "Add username scheme and hashing support" refers to the same functionality we've already implemented in WAT?

[bgins]

@avivash yep, the work is similar, but we would want to generalize the interface to give developers the option to hash or not. The main reason for that is backwards compatibility with existing usernames, but going forward some developers may want a plain name so their users have a nice domain name on the HTTP gateway like https://yeti.files.fission.name/.

The other consideration is whether or not to support username schemes. The idea with schemes is the developer could define a templated username that includes the app's domain name that would create a namespace for users. We could potentially skip this part for now. There are some great benefits to the hashing part on its own.

My intuition is that filesystem recovery and hashing support will be independent features in Webnative. If you're up for both, I think adding hashing support would be great! Let's maybe chat about it, and I can share some additional context.