The new ResourceID is really a database ID (in our case, a LDAP DN),
and we have completely decoupled other request attributes like type
and owner from it.

Resource ownership checks are now delegated to the backend.

Also change the backend CreateResource call to CreateResources, taking
multiple resources at once, so we can perform user-level resource
validation, and simplify the CreateUser code path.

The shard is kept in sync with the email resource shard. CreateUser
validation enforces a single email resource per account.

If the user has no encryption keys, we'll initialize them on password
changes. This feature is controlled by a configuration parameter.

Still poor validation, but at least not wrong.

Still poor validation, but at least not wrong.

Referring to the account is clearer. Also add account recovery
integration tests, and a test fixture with encryption keys.

Structure flow around requests themselves and composition rather than
handlers and wrappers, the results are likely more readable (and
shorter).

Move all the user auth management business logic to a smart RawUser
object, to separate it from details of API handling. The result should
be more understandable: all critical changes are contained within a
single type.

Also, with all the workflow driven by Requests, we can get rid of the
boilerplate in the HTTP API server and replace it with a tiny tiny
layer of reflection.