Tests for creating/retrieving metadata revisions, remove broken alternative revision path

[spencerjanssen]

This adds test coverage for:

1. Uploading revised package metadata
2. Downloading revised package metadata via revision number paths like /package/testpackage-1.0.0.0/revision/1.cabal
3. Downloading revised package metadata via version-revision paths like /package/testpackage-1.0.0.0/revision/testpackage-1.0.0.0-r1.cabal

The first and second tests pass. The third does not, this is #1439.

113d4df introduced version-revision paths. I question whether this feature ever worked. The resourceAt definition here:

hackage-server/src/Distribution/Server/Features/Core.hs

Line 461 in 113d4df

coreCabalFileRevName = (resourceAt "/package/:package/revision/:tarball-:revision.:format") {

Is parsed as [DynamicBranch "tarball-:revision",StaticBranch "revision",DynamicBranch "package",StaticBranch "package"]. The code expects to find separate tarball and revision in DynamicPath but won't get them.

I'm not sure what the proper way forward is here. Does it make sense to revert 113d4df? I'm not sure what use-case it was trying to fulfill.

Update: I went ahead and reverted 113d4df. The longer revision URLs don't work, probably never worked, aren't trivial to fix, and the purpose of them is unclear.

[gbaz]

Thanks for this! That user seems deactivated and their PR if it ever existed is deleted. Not sure what it was all about, but might as well go.