cargo: make vss-server/impls easier to consume as a library

[phlip9]

server+impls: make postgres native TLS optional

The native-tls crate adds a ton of build headache that I'd like to
avoid if I'm not actually using it. This diff makes it possible to
disable it.

cargo: relax direct dependency version requirements

Make it easier to consume VSS crates as a library. I've limited direct
crate dep semver versions to the first MSRV+semver compatible crate that
compiles and passes all tests.

• tokio-v1.30 is the first version that supports OnceCell::const_new
  without the parking_lot crate enabled

[ldk-reviews-bot]

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[phlip9]

Looks like vss-server also needs something like lightningdevkit/ldk-node#1092 to fix MSRV CI checks

[tnull]

Not opposed to the change, but could expand a bit on a) what headache you're referring to exactly and b) what's your use case for using the crates independently from the vss-server binary?

Changes themselves LGTM I think.

[phlip9]

Sure, let me expand on this a bit:

a) We try really hard to use only one TLS stack (rustls) as much as we can. This is for hardening (avoid exposing more non-memory safe code to the open internet), build convenience (it's slightly annoying to configure openssl+pkgconfig in nix builds and dev machines), dependency minimization, reduced binary bloat, and reduced CI build time. So pulling in openssl and the native-tls crate is something I would like to avoid.

b) We're now running an internal VSS (inside our VPC with mTLS auth). It was actually really nice just pulling in the VssService hyper service from server/src/vss_service.rs and serving it on top of all our existing Rust tooling. This integrates cleanly into our e2e tests, gets all our logs+traces+metrics tooling, mTLS config, instrumented allocator, etc ~ for free. It's not that we can't do this as a separate "opaque" service behind nginx, but then it's definitely harder to test.

[tnull]

Sure, let me expand on this a bit:

a) We try really hard to use only one TLS stack (rustls) as much as we can. This is for hardening (avoid exposing more non-memory safe code to the open internet), build convenience (it's slightly annoying to configure openssl+pkgconfig in nix builds and dev machines), dependency minimization, reduced binary bloat, and reduced CI build time. So pulling in openssl and the native-tls crate is something I would like to avoid.

b) We're now running an internal VSS (inside our VPC with mTLS auth). It was actually really nice just pulling in the VssService hyper service from server/src/vss_service.rs and serving it on top of all our existing Rust tooling. This integrates cleanly into our e2e tests, gets all our logs+traces+metrics tooling, mTLS config, instrumented allocator, etc ~ for free. It's not that we can't do this as a separate "opaque" service behind nginx, but then it's definitely harder to test.

Okay, makes sense (though I'm not sure where I stand on the rustls vs openssl arguments, but that is for an orthogonal discussion, trade-offs everywhere).

So, happy to have this land from my side, but @tankyleo still needs to review.

[phlip9]

Pushed a separate PR to fix MSRV CI issues: #117