Right now, RSS always provides an empty list of initial TLS certificates (for the external API) to Nexus during rack initialization. On a real system, the user will provide the initial certificate over the technician port during initial setup (see RFDs 57, 323). This means Wicket will get them, and it will need to provide them to RSS. This PR adds these as a parameter to RSS's rack-initialize endpoint.

This affects different environments:

• In a "real" system (which is just dogfood right now), this will need to be provided by whoever's crafting the initial RSS request. For Dogfood, we'll want to take the existing certificate and key and put them in PEM format into the initial RSS request.
• In the CI helios-deploy job that runs end-to-end tests, in this PR we generate a self-signed certificate, have RSS get that, and have the end-to-end tests reqwest client explicitly trust this certificate.
• In other non-simulated dev environments (i.e., if you deploy on your own using the how-to-run instructions), if you do nothing, you will have no certificates. (No change from today.) Nexus will only listen over HTTP. You can provide certificate(s), in which case Nexus will listen over HTTPS, too.
• In simulated environments (including the test suite), you will have no certificates. (No change from today.)

Fixes #1528.

This also addresses one of the two remaining items in #1529. The other one is notifying Nexus instances when one of them receives a certificate update. In an upcoming PR, I intend to instead have Nexus instances have a background task to monitor the list of certs.