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.

It makes more sense to have this directly on the User object.

Adds UIDs to users, websites, DAV accounts.

Assign a random UID to newly created users, and ensure that all
associated resources have the same UID as well.

Check passwords and recovery responses directly against backend data.

Still doesn't entirely solve the problem of encoding the U2F
registration requests on the client side (we should probably just
accept a bytestring), but all the important functionality is there.

Rename queryConfig to queryTemplate to better reflect its purpose, and
drop all cruft that had to do with config deserialization.

Implement a password recovery endpoint, and a way to set the recovery
hints (in the current model, it's a hint/response system).

Start a full HTTP server, backed by an in-memory LDAP server, and test
the API directly.

Use a lower level type to abstract LDAP "transactions" (really just
batches of changes) and generate a set of ModifyRequest objects at
commit time. Change the API to let the caller manage the
transaction (TX object) lifetime.

This should make it easier to implement a SQL backend in the future if
necessary, even though LDAP knows no such thing as transactions.

As a result of a better low-level interface, reducing the boilerplate
LDAP code, the business logic in model.go should be quite more
readable.

This includes a number of validators meant to support the creation of
new users and resources (for instance by checking for resource ID
uniqueness etc).

The result is a functional server, altough there aren't nearly enough comments.