Consider making the TLS implementation used in shuttle-shared-db configurable

[aumetra]

(Opening this issue based on a question asked on Discord)

Currently the SQLx connection pool provisioned by shuttle-shared-db uses native-tls to establish a secure connection to the database server.
Would it be thinkable to gate these behind features like rustls and native-tls, where one of them is set as the default? (this would be a breaking change)

---

Looking at the SQLx source code, they use the webpki-roots certificates for their trust anchors.
So if Shuttle installs their own CA certificates, using the rustls feature will break it.

[moritzheiber]

This is especially relevant if you're using sqlx in your application already (e.g. to run migrations or query the database) and don't wish to rely on native-tls as a feature of the crate (i.e. you cannot have the sqlx dependency of shuttle-shared-db built with native-tls and your own version of sqlx with e.g. rustls)

[oddgrd]

The thing I'm not sure about here is that since we use native-tls everywhere else (which we might also be able to change, but that needs investigation), will using rustls here then conflict? If someone wants to explore this in a PR and prove that it works, I think we can add this feature flag to shuttle-shared-db.

[utterstep]

@oddgrd can you assign this to me & @vroussea (Team V²)? :)
We'd like to try this now, as #864 PR passed the review.

[oddgrd]

@utterstep awesome! I sent you an invite now to get the triager role on this repo, this should allow you to add labels and set assignments

[aumetra]

Closed by #870