Upgrade to rustls 0.23

[djc]

Upgrade rustls to 0.23.x. The tricky part here is that rustls since 0.22 exposes two CryptoProvider implementations here. So far I've exposed separate features for each, but this still runs the risk that a project that ends up with crates selecting rustls with different crypto providers picks an unexpected one. I guess there's not much of a solution for that, but open to feedback about what you think the right direction is for sqlx.

[djc]

Feels like the test matrix gets fairly extreme. IMO it doesn't really make sense to test the matrix of TLS implementations (x crypto providers) against all database versions, but that's sort of orthogonal.

[abonander]

It is rather important, because it's caught incompatibilities that have crept in upstream: #3091

[djc]

Oh, I could absolutely see testing recent versions of the databases against all TLS stacks (and potentially crypto providers), just not sure it's all that valuable to do this against the entire back catalog of database versions.

[abonander]

It's not the entire back catalog, the policy is the oldest and newest actively supported versions.

MariaDB is a bit of a special case because we added the verylatest tag at the request of one of the maintainers.

If there are any versions that don't fit with this policy, it's just because the file hasn't been updated.

As for testing Ring vs aws-lc-rs, it depends on whether or not RusTLS guarantees they support the same cipher suites, etc. If they do, then just testing one is fine. Otherwise, it seems prudent to cover them both.

I don't care as much anymore about the number of CI passes as I used to. I'm perfectly happy to let Micro$oft foot the bill.

[djc]

Crypto providers might definitely have different cipher suites.

[abonander]

Can you add a note about crypto providers to https://github.com/launchbadge/sqlx/blob/main/src/lib.md#tls-support?

[djc]

Can you add a note about crypto providers to https://github.com/launchbadge/sqlx/blob/main/src/lib.md#tls-support?

Done.