.update-copyright.conf: Automate maintenance for AUTHORS

Use my external update-copyright package [1] to maintain the AUTHORS
file.  Don't maintain the copyright blurbs though, since this project
sticks to:

  Copyright (c) 2014 Docker.
  <Apache blurb>

and doesn't list the file's individual contributors.

[1]: http://pypi.python.org/pypi/update-copyright/
.mailmap: Standardize author names and addresses

The syntax is described in the MAPPING AUTHORS section of
git-shortlog(1).  I looked for oddities and obvious duplicates in the
list of all commit authors, and added entries here that looked
reasonable to me.  When someone used multiple email addresses, I've
chosen to standardize on whichever address they used for their last
commit.  I haven't contacted any of these folks to confirm my choices.
AUTHORS: Run update-copyright.py to update this from the Git history
Obsolete Nginx basic_auth link
Merge pull request #744 from Jasperswaagman/master

Obsolete Nginx basic_auth link
Debugging tips and tricks
Lock out setup_database method
Merge pull request #772 from docker/710_lockout_db_setup

Lock out setup_database method
Merge pull request #754 from docker/debugging

Debugging tips and tricks
Reconnect to search backend DB when it disconnected
Merge pull request #779 from hex108/fix-issue-778

Fix issue 778:  OperationalError: (OperationalError) server closed the connection unexpectedly
Merge pull request #669 from wking/update-copyright

Automate maintenance for AUTHORS with update-copyright
Drop the old tarsum computation for Docker <0.10

This landed in 82021b4 (Merging bypass-tarsum, 2014-04-07, #300), but
those Dockers are now ancient history.

I'm against this sort of user-agent-dependent behavior in general.  If
we want to version the API, it makes sense to have version checks in
one place (e.g. in the URL, or in an explicit Docker-Version header,
or in the PUT payload, ...). I'm happy with either the URL approach
(always explicit) or the Docker-Version approach (defaulting to the
current version). If we make some small change to the API (such as not
storing layer tarsums), and want to add per-feature headers or
registry-side options to enable/disable this behaviour, that's
fine. If we can auto-detect new features (e.g. if
Docker-Checksum-Payload exists, it must be using the new SHA-256
semantics), that's fine too. But regardless of how we version the API,
conflating the API version with the user-agent version just seems
confusing.

Olivier wants us to warn older clients instead of just failing when
their tarsum doesn't match our checksum [1], so we still need to use
their user-agent string to decide which clients get warned.  I've
softened the old DockerVersion into a more relaxed
docker_client_version, which no longer rejects non-Docker clients [2].
If we can't version the API, we can at least use a blacklist to deny
old implementations instead of a whitelist that requires other clients
to fake the Docker-daemon User-Agent string.

For the 'PUT /v1/images/<image_id>/checksum' endpoint, we don't need
to rely on the user-agent, because the old X-Docker-Checksum was
replaced by the new X-Docker-Checksum-Payload.  If the client isn't
setting X-Docker-Checksum-Payload, just say that in the error message
and hint that it might be due to an outdated client.

I'd like to remove all the user-agent-dependent behavior, but we're
currently also using it to setup some tag metadata in
docker_registry.tags.put_tag.  I don't touch that here, since I
haven't tracked down the reasoning behind that behavior (although I
suspect it's also a bad idea ;).

I also haven't touched the user-agent bits under tests/, since I
haven't checked to see if they're designed to test this check, or to
test the put_tags check, or just to bypass either of those checks.

[1]: https://github.com/docker/docker-registry/pull/570#issuecomment-62963997
[2]: https://github.com/docker/docker-registry/issues/375