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.