CI: Remove fly.io in favour of SSH into production server.

Less stress on quicklisp.org as well. Should see great speedup.

Although obsolete at the time of consultation,

https://blog.benoitblanchon.fr/github-action-run-ssh-commands/

saved me some time.

Previous commentary on Fly.io...

Build a [[https://opencontainers.org/][container]] image to easily deploy said executable binary on servers,
making it accessible from the World Wide Web.

In partnership with Cloudflare we use [[https://fly.io][Fly.io.]] In exchange for placing our
executable binary inside a Docker container image, Fly.io will turn it into a
lightweight virtual machine (VM) through [[https://firecracker-microvm.github.io/][Amazon Firecracker]] and run it on their
servers. Lovely. Fly.io differs from VPS providers like Hetzner by offering
optional prepaid usage based pricing over contract based pricing. What tips the
balance in their favour is the awesome team ([[https://fly.io/blog/][great technical blog posts]]) and the
generous free monthly allowance. It makes hobby projects affordable to host and
expand. I'm very impressed, go give them a try, and no, I have no affiliation
with them other than that of a happy customer.

The typical analogy I have heard to explain Docker containers is to compare them
to an intermodal shipping container. Can you imagine shipping transatlantic
cargo without standardized containers? It makes deployment of software much
easier when the abstraction level goes as close as possible to the hardware.
Like their metal counterparts, a software container image can be compared to a
process with constraints placed by the kernel (the captain goes down with his
ship) with an isolated filesystem that may have some holes poked through (though
I'm sure modern shipping containers are considerably more rust-proof).

Github and Fly.io are well integrated. It simplifies the process of moving
development code to production code to =git push origin/master=. This is done in
[[https://github.com/HanshenWang/project-isidore/blob/master/.github/workflows/CICD.yml][CICD.yml.]]

With how simple the application and dependencies currently are, it's arguable if
a Dockerfile (aka a 16 line shell script) is even needed. Using Common Lisp on
Heroku necessitates a custom buildpack (aka a 100 line shell script) anyways.