[WIP]Caching exposed modules for Hackage packages in Pantry DB

[qrilka]

Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.

Please include the following checklist in your PR:

• Any changes that could be relevant to users have been recorded in the ChangeLog.md
• The documentation has been updated, if necessary.

Tested manually.

[qrilka]

Fixes #4536

[qrilka]

@snoyberg could you take a look at this variant? On my machine for stack script --resolver=lts-13.0 hmm.hs from #4536 I get the following:

version	time
master	4.4s
this PR, migrated, not cached	5.4s
this PR, cached modules	1.2s
1.9.3	0.4s

From logs it looks like lock files could give a bit more improvement and probably we could get something like 2x slowdown comparing to the current stable version. Also I have an idea to store module list as a blob (maybe even in hackage_cabal table) - this could save us some time by not doing some lookups.
Do you think it make sense to explore that option?

[snoyberg]

We can discuss this if the overall idea isn't clear here. But: instead of performing as much logic in the Haskell side, what about pushing the lookup logic into the SQLite database instead? I'm picturing something like this:

SnapshotModuleCache
    someUniqueSnapshotIdentifier Text

SnapshotPackage
    snapshot SnapshotModuleCacheId
    cabal BlobId
    UniqueSnapshotPackage snapshot cabal

PackageExposedModule
    cabal BlobId
    module ModuleId
    UniquePackageExposedModule

Then on the Haskell side:

-- Ensures that the tables are filled in for a snapshot
populateSnapshotModuleCache :: Snapshot -> RIO env ()

-- Find all packages which contain the given module name
findPackagesWithModule :: Snapshot -> ModuleName -> RIO env [PackageName]

I have the details very wrong above, but I think with this you could:

• Have a relatively slow populate action, with a sticky log message explaining "populating module name cache." This will happen once, and the first usage of a snapshot is already expected to be a bit slow, what with downloading the snapshot file and such.
• Have a much smaller surface area for data transfer between Haskell and SQLite for each module name lookup

[snoyberg]

I think we've been trying to avoid adding dependencies on these kinds of packages.

[snoyberg]

Since there are likely to be a lot of duplicated module names, this would probably benefit from normalization, the same way we normalize package names. How about:

    moduleName ModuleId

Module
    name P.ModuleName
    UniqueModule name

Or something like that?