Introduce data store abstraction layer

[tomjaguarpaw]

There are conflicting opinions about whether an incremental rewrite of hackage-server is feasible (see Expressed opinions). This PR starts moving in one possible direction by abstracting out the functions that deal with the acid-state data store. Specifically, for a subset (see Subset) of hackage-server's components it does the following:

• moves the <component>StateComponent function into the component's Acid module
• introduces a component-local abstraction layer with Backend and Store
• instantiates the Backend from the existing acid-state implementation in a function called acidStore

This PR is a pure refactoring with no change in behaviour. It seems to me that after this refactoring we could, for each component in the subset, subsequently swap out acid-state as the data store and replace it, with, for example, Postgres, by defining an appropriate value of type Backend. I'm not sure that would get us to "good design" but as far as I can tell it would work.

The branch is structured as a sequence of trivial refactoring commits.

Is there something I've missed that makes this approach unviable?

• Perhaps, contrary to my assumption, it's not easy to swap in Postgres
• Perhaps we could swap in Postgres like this, but somewhere down the line we're going to hit a dead end
• Maybe some other reason

I would welcome any clear explanation of why this approach is unviable, because I don't understand why yet. If it is unviable then it will be very helpful to have an explanation written down clearly.

---

Specific improvement example

This replaces several direct uses of the following, where consumers first fetch the entire package index and then operate on a smaller piece of it:

queryGetPackageIndex :: m (PackageIndex PkgInfo)
PackageIndex.lookupPackageName :: PackageIndex PkgInfo -> PackageName -> [PkgInfo]
PackageIndex.lookupPackageId :: PackageIndex PkgInfo -> PackageId -> Maybe PkgInfo
PackageIndex.allPackagesByName :: PackageIndex PkgInfo -> [[PkgInfo]]

with these new fields of CoreFeature, which only return the subset of the package index actually required to implement a particular piece of functionality:

queryLookupPackageName :: PackageName -> m [PkgInfo]
queryLookupPackageId :: PackageId -> m (Maybe PkgInfo)
queryLatestPackages :: m [PkgInfo]

backed by the following fields of the Core Store:

lookupPackageName :: PackageName -> m [PkgInfo]
lookupPackageId :: PackageId -> m (Maybe PkgInfo)
latestPackages :: m [PkgInfo]

The current acid-state implementation defines these in terms of its existing PackageIndex, but consumers no longer need to fetch the whole PackageIndex just to perform package-name lookup, package-id lookup, or latest-version-per-package selection. A future alternative Backend could take advantage of these new methods to load less into memory.

In particular, I am more optimistic than the "Why Incremental Refactoring is not Feasible" section of the Modernising Hackage Server proposal.

---

Subset

This PR deals with these components: AnalyticsPixels, Core, HaskellPlatform, Mirror, TarIndexCache, Votes

Expressed opinions

For example:

migrating from the acid-state alone without touching other bits such as migrating out of happstack not feasible from the time and energy investment perspectives

qnikst haskellfoundation/tech-proposals#67 (comment)

I think an incremental rewrite is actually pretty plausible.

dcoutts haskellfoundation/tech-proposals#67 (comment)

[tomjaguarpaw]

Maybe this doesn't get to the heart of the suggested infeasibility, as discussed at: https://github.com/tweag/tech-proposals/blob/tweag/proposal-modernising-hackage-server/proposals/0000-modernising-hackage-server.md#why-incremental-refactoring-is-not-feasible

OK, now updated to deal with that.