certbot: Clean up to use --standalone rather than waiting for nginx to start

[timabbott]

The initial certbot implementation in #139 is super handy, but it has a somewhat awkward mechanism where we first generate a self-signed cert (so nginx will start), and then boot the machine (running the certbot job in the background), and the certbot job waits for nginx to start, and then runs certbot to create the cert.

It would be cleaner to e.g. run certbot for this purpose with certbot --standalone (rather than the nginx mode) before we've started nginx (which happens indirectly through the supervisord startup); that would eliminate the need for both the temporary self-signed certificate as well as the run-in-the-background messyness.

[i5hi]

With SSL_CERTIFICATE_GENERATION: "certbot" when I access our zulip server at the given domain, it still uses the self-signed certificate.

Additionally, if I run docker-compose restart the zulip container is stuck at an interactive certbot promt as follows:

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/zulip.stackmate.org.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
An unexpected error occurred:
EOFError
Please see the logfiles in /var/log/letsencrypt for more details.
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 

[i5hi]

I had to run ./sbin/certbot-deploy-hook inside the Zulip container to get it to work

[andersk]

Using standalone mode isn’t a good plan because it would reintroduce zulip/zulip#20593.

(For those reporting that current certbot support is broken, that’s a different issue: #381.)