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

[tankyleo]

nit: this seems a little out of place, can we delete it ?

[phlip9]

yeah now that I look at it, it definitely feels a bit tacked on. I'll remove this line.

on a related note, I notice there's no docs for the jwt or sigs features (now also none for postgres-native-tls). EDIT: nvm, I see brief mention in getting-started.

when looking at a new crate, I usually skim through the docs for an "Optional features" list like https://docs.rs/hyper/latest/hyper/#optional-features. so we should probably add similar somewhere. normally I would put that in the README.md or top-level crate lib.rs.

though, the current README.md reads more like a design doc than a project landing page. it might be worth placing more of the content from doc/getting-started.md more upfront in the README and put more of the current README into a doc/design.md

[phlip9]

added a small section to getting-started

[tankyleo]

We don't update the Cargo.lock file in commit 4238833 so I am worried we may ship a piece of code in the future that no longer works with the declared minimum versions in this commit.

Is it worth adding some automated testing for this case ?

[phlip9]

sure, I usually do something like this in CI:

# Remove dev-deps from Cargo.toml to prevent `cargo update` determining minimal
# versions based on dev-deps.
cargo hack --remove-dev-deps --workspace

# Resolve direct dependencies using the min. version in our Cargo.toml's.
RUSTC_BOOTSTRAP=1 cargo update -Z direct-minimal-versions

cargo check --workspace

I'll add this

[phlip9]

done

[tankyleo]

[Some buggy github stuff ignore this]