We pick `containers` here instead of `registry` because there could
clearly be a case made for a `registry` that's not specific to GitLab,
Docker, TPA, or anything internal like this. `registry` is way too
generic of a name, while `containers` says what it is, it's a
repository of "containers" ("images" is implied here, of course).

This is crashing the Golang crypto/tls library which doesn't support
DH exchanges and argues instead for ECDH exchanges instead:

https://github.com/golang/go/issues/38788

Furthermore, it doesn't make sense to embed the DH parameters on
certificates in the first place, according to this:

https://stackoverflow.com/a/58221273

Quote:

> There is nothing like DH parameters in a certificate.
>
> DH is only one of ways how a public key can be used. You may
> generate a DH public key with specified length (e.g. 2048 bit) and
> execute the DH exchange, but it has nothing to do with certificate
> parameters. (didn't you mean to generate a keypair, not a
> certificate?).
>
> Indeed the DH key exchange needs other parameters (p, g), but the
> parameters are part of the protocol, not the certificate. In TLS
> even the DH parameters can be random and authenticated by the
> certificate's public key - it is called Ephemeral Diffie-Hellman key
> exchange.
>
> You could generate DH parameters (p, g) separately:
>
>     openssl dhparam -out dhparams.pem 4096

I believe that if those are not provided with the certificate, the
default system-wide ones (`/etc/ssl/dhparam.pem`) will be used, and I
think that's fine for our cases.

In any case, I agree with golang that we should just ephemeral DH
parameters anyway.

Partly related to the ciphersuites improvement as
well (tpo/tpa/team#32351).

Surely the first hunk in that patch was a typo...

This partially reverts commit 71484562801c5120a84fc9d04fbf37e64bc38ae6.