Remove bit.ly integration

[ghost]

There was some concern about sending users to a 3rd party for executable/data files (vs the normal webpages we usually use mzl.la for).

We could CNAME f.mzl.la to our s3 bucket and use URLs from there. Whether or not we shorten the URL, the fragments are still long, so it probably doesn't matter much.

[ghost]

@jvehent 's diagram: https://screenshots.firefox.com/bKPGXo8apaV0YSS2/knsv.github.io

[jvehent]

sequence diagram, for archiving, in mermaid format:

sequenceDiagram
participant firefox
participant nodejs
participant s3
firefox->>nodejs: GET f.mzl.la/somefile
nodejs->>firefox: 302 s3.aws.com/somebucket/somefile
nodejs->>nodejs: mark file for deletion in 24h max
firefox->>s3: GET s3.aws.com/somebucket/somefile
firefox->>nodejs: DELETE f.mzl.la/somefile
nodejs->>s3: delete /somebucket/somefile

[dannycoates]

I'm +1 for not using bitly.

@jvehent Is there a specific reason you're using a 302 in this flow? We're currently proxying the download through the service so that we can trigger the delete right away if the file is successfully (fully) sent. (also to save the client another request but nbd)

[jvehent]

No particular reason, other than removing pressure from the application server (and maybe bandwidth cost to, but unsure about that one). @oremj may have a stronger opinion on file download best practices.

[fmarier]

Also, the bit.ly links are HTTP. We should avoid standing up a service that uses this deprecated protocol :)

[pdehaan]

Fixed via #123; "removed bitly integration".