patches: add a per-repository patch index

- this fixes a bug where if we save a concretized sug-DAG where a package
  had been patched by a dependent, and the dependent was not in the DAG,
  we would not read in all patches correctly.

- Rather than looking up patches in the DAG, we look them up globally
  from an index created from the entire repository.

- The patch cache is a bit tricky for several reasons:

  - we have to cache information from packages, specifically, the patch
    level and working directory.

  - FilePatches need to know which package owns them, so that they can
    figure out where the patch lives.  The repo can change locations from
    run to run, so we have to store relative paths and restore them when
    the cache is reloaded.

  - Patch files can change underneath the cache, because repo indexes
    only update on package changes.  We currently punt on this -- there
    are stub methods for needs_update() that will need to check patch
    files when packages are loaded.  There isn't an easy way to do this
    at global indexing time without making the FastPackageChecker a lot
    slower.  This is TBD for a future commit.

  - Currently, the same patch can only be used one way in a package. That
    is, if it appears twice with different level/working_dir settings,
    bad things will happen.  There's no package that current uses the
    same patch two different ways, so we've punted on this as well, but
    we may need to fix this in the future by moving a lot of the metdata
    (level, working dir) to the spec, and *only* caching sha256sums in
    the PatchCache.  That would require some much more complicated tweaks
    to the Spec, so we're holding off on that til later.

- This required patches to be refactored somewhat -- the difference
  between a UrlPatch and a FilePatch is still not particularly clean.

0 files changed, 0 insertions, 0 deletions