index: Whitelist 'id' and 'checksum' keys for image data

The image data behind the "repository images" endpoints is documented
as only having these two keys [1], but on my existing docker-registry
instance, I see additional keys:

  # cat /var/lib/docker-registry/repositories/wking/gentoo/_index_images  | jq .
  [
    {
      "id": "9917ba282bd23e78d1caa25aac74fb9d5d305aee10db0ef84f3230ef7fc93c59",
      "Tag": "latest"
    }
  ]

Instead of storing any image-specific data that the user sends up,
this commit restricts the set of allowed keys.  This avoids
interfering with the Server.pullRepository code in the Docker source,
which uses the presence of img.Tag to decide whether or not to
download the image [2].  It also avoids trouble with the Docker server
trying to store auxiliary tags in the hard-coded ImgData struct [3].
The drawback to this extra protection against over-eager clients
pushing undocumented keys is that we'll have to update the whitelist
if new keys are added to ImgData.  This commit also doesn't cull
undocumented keys from existing image index files.  Folks with
existing registries can use jq [4] to remove them by hand.  In POSIX
shell:

  JQ='[.[] | {"id": .id, "checksum": .checksum}] | del(.[][] | select(. == null))'
  for FILE in $(find /var/lib/docker-registry/repositories/ -name _index_images)
  do
    FILTERED=$(jq "${JQ}" < "${FILE}")
    echo "${FILTERED}" > "${FILE}"
  done

[1]: http://docs.docker.io/en/latest/reference/api/index_api/#repository-images
     PUT /v1/repositories/(namespace)/(repo_name)/images
     GET /v1/repositories/(namespace)/(repo_name)/images
     PUT /v1/repositories/(repo_name)/images
     GET /v1/repositories/(repo_name)/images
[2]: https://github.com/dotcloud/docker/blob/v0.8.1/server.go#L1179
[3]: https://github.com/dotcloud/docker/blob/v0.8.1/registry/registry.go#L673
[4]: http://stedolan.github.io/jq/
search: Stub out a preliminary search index

This implements the

  GET /v1/search

endpoint using a simple JSON object for storage and a global Python
dict for live access.  That's not going to scale well for large
registries, but it's a start.  Benefits of this approach:

* We automatically support all the existing storage backends.
* The in-memory Python dict gives fast read-only access.

Drawbacks to this approach:

* Searches iterate over all key/value pairs (there's no precompiled
  index), so they'll be slow if you have tons of repositories.
* We write the whole index to the storage backend whenever a
  repository is created, updated, or deleted.
* If you have multiple registries sharing the same storage backend
  (e.g. gunicorn workers), your in-memory Python indexes will go
  out-of-sync, and may end up clobbering changes that other registries
  made to the stored index.

So this is basically a proof-of-concept for small registries.  A more
serious implementation would use an external SQL database to overcome
all of these limitations.  That should be easy to add later; for now
I'm focusing on getting the internal logic right.  Slotting in a
better backend later should be easy.

Because the search index code is only bound to registry.index by
signals, I've moved it into it's own registry.search module.  I added
a commented-out:

  #index = Index()

in the global-declaration section of the new module, to remind folks
that we would be creating a global 'index' object.  We can't actually
declare the global at that point though, because the Index class
hasn't been defined yet.

There's a version stamp in the saved index, and a missing index file
counts as v0, so folks who have been running earlier versions of
docker-registry will have their index built automatically the next
time they start the app.
README.md: Document _env: syntax defaults

Catch the docs up with 7762af1 (Added support for environment variable
default value, 2013-12-09).
run.sh: Remove --debug argument

This doesn't do anything constructive in Gunicorn v18.0, and having it
around just interferes with --preload [1].

[1]: https://github.com/benoitc/gunicorn/pull/701
run.sh: Add '$GUNICORN_OPTS "$@"' to gunicorn invocation

This allows users to add custom arguments via the command line ($@) or
environment ($GUNICORN_OPTS), which is useful if you want to --preload
(or tweak some other setting) without editing your config file.
search: Use SQLAlchemy as a search-index backend

This avoids storing search-index state in the local process (as the
previous Python-dict-based implementation did).  Multiple registry
processes (e.g. gunicorn workers) can now use the same search-index
database and stay in sync with each other.
index: Factor out the SQLAlchemy Index into flexible backends

Make it easy to add alternative backends for the search endpoint.
I've added a 'search_backend' config and renamed the 'search_index' to
'search_sqlalchemy_database' to avoid colliding with other backends.

Reported-by: Lee Trout <ltrout@newsinc.com>
index: Expand load() to handle arbitrary module names

It would be nice if users could point to their own index
implementations if a suitable backend is not supplied by
docker-registry.  This commit adds support for loading Index
implementations from arbitrary modules.

Reported-by: Lee Trout <ltrout@newsinc.com>
index: Add '# nopep8' tags to long URL lines

This makes the lines even longer, but avoids tox failures:

  /.../registry/index.py:110:80: E501 line too long (116 > 79 characters)
  /.../registry/index.py:111:80: E501 line too long (112 > 79 characters)

Alternatively, we could ignore E501 entirely (with an entry in
tox.ini's flake8.ignore), but Sam Alba prefers ignoring just those
lines (and not all long lines) [1].

[1]: https://github.com/dotcloud/docker-registry/pull/247#issuecomment-36075734