tags: Extend delete_tag to remove additional metadata files

Storage.repository_tag_json_path and (if the tag == 'latest')
Storage.repository_json_path are both created by put_tag, so we should
remove them in delete_tag.
storage: Add Storage.repository_path

Besides factoring out a bunch of repetitive

  {self.repositories}/{namespace}/{repository}

construction, this gives us a path to recursively remove when we want
to delete a repository.
signals: Add repository-* signals

These aren't wired up yet; I'll do that in subsequent commits.
index: Trigger repository-created and repository-updated signals

Passing in the parsed JSON image data (ids and checksums).
index: Move delete_repository over from the tags module

The rename from

  DELETE /v1/repositories/<namespace>/<path:repository>/

(which matches the spec [1]) to

  DELETE /v1/repositories/<namespace>/<path:repository>/tags

(not in the spec) happened in 1026a87 (renaming DELETE call on a
repos, 2013-06-26), but the motivation behind the rename is unclear.
I'm also not sure why a delete_repository function is in the
registry.tags module (which already has the expected delete_tag
method).

This commit restores the original URL, shifts the function to the
index module, triggers tag-deleted signals for each tag, removes the
remaining repository data en masse, and triggers the
repository-deleted signal.  It doesn't remove referenced images,
because those images might be required by other repositories.  We'd
want some sort of refcounting (number of repositories/tags requiring
this image) to decide when image-removal was allowed.
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