Fix GitHub archive URL for packages

[robbiemcmichael]

When registering new packages, the GitHub archive URL includes a slash at the end. This works in most situations as github.com is lenient about forwarding requests with or without the slash to codeload.github.com, however, it can cause issues with some caching proxies.

---

Taking elm/html as an example, archive URLs with or without the slash redirect correctly:

$ curl -sS https://package.elm-lang.org/packages/elm/html/1.0.0/endpoint.json | jq .
{
  "url": "https://github.com/elm/html/zipball/1.0.0/",
  "hash": "52e43c64aed979dacb444f5147ee475e9610079f"
}

$ curl -sSi https://github.com/elm/html/zipball/1.0.0/ | grep Location
Location: https://codeload.github.com/elm/html/legacy.zip/1.0.0

$ curl -sSi https://github.com/elm/html/zipball/1.0.0 | grep Location
Location: https://codeload.github.com/elm/html/legacy.zip/1.0.0

However, when using a caching proxy like Artifactory (which is unfortunately often a requirement when building software in large enterprises) we can run into the following issue:

$ curl -sS https://artifactory.domain/artifactory/github/elm/html/zipball/1.0.0/
{
  "errors" : [ {
    "status" : 404,
    "message" : "{\"error\":\"Item github-cache:elm/html/zipball/1.0.0 does not exist\"}"
  } ]
}

This is because the slash makes Artifactory thinks the request is for a directory. As nothing has been cached within that directory, it returns an error saying the directory doesn't exist. Even if you force it to cache the file then it will still reject requests because it has cached a file under that path instead of a directory. Dropping the slash on the archive URLs fixes the problem.

---

From what I can tell, this only solves the problem for new packages. If this gets accepted and rolled out, the next question is whether you're open to editing the package database to drop the slashes on all the existing packages.