electrsd: include in workspace and CI

[satsfy]

Closes #552

• Include electrsd in the workspace so it is built, linted, and tested alongside the other crates, mirroring the bitcoind crate pattern.
• Apply cargo fmt and clippy fixes in electrsd
• Updates the lockfiles with ./contrib/update-lock-files.sh
• Make electrs_0_10_6 the default version feature. Version features are now chained like bitcoind as a version cascade: electrs_0_10_6 -> 0_9_11 -> 0_9_1 -> 0_8_10 -> esplora. --all-features resolves to 0.10.6.
• Version-specific behavior is identified in versions.rs with legible constants USE_LEGACY_COOKIE (replacing old legacy feature), USE_JSONRPC_IMPORT, USE_VERBOSE_ARG.
• Esplora is tested with --no-default-features so it does not accidentally combine with the default electrs version.
• no-download job now enables bitcoind_download because it still needs a bitcoind binary while using the system-provided ELECTRS_EXEC.
• Corrected the bitcoind 23_2 feature name in ee9443c.
• Make electrsd CI coverage easier to debug by putting RUST_LOG=debug on electrsd jobs.

Tests now include electrsd. Check by running: cargo test --all-features

I've had various versions problems. Ran a CI matrix of every bitcoin version and electrds in Ubuntu 24.04 to understand what would work with what.

[satsfy]

One thing I thought to include is a default electrsd version, like bitcoind in 0_17_2, I suppose either 0_8_10 or 0_10_6. I have not included a default because it required including std (for bitreq's get() to download), and I'm not sure if it's this PR's scope.

Edit: I suppose we need the default so tests work with an explicit version.

[satsfy]

Latest force push improves the legibility of the solution, sets a default electrs version, reworked the version feature graph so the cfg cascade in versions.rs is unambiguous. Replaced the legacy feature with versions::USE_LEGACY_COOKIE so --all-features tests pass.

[tcharding]

Needs rebase mate. Out of interest what made you go with electrs_0_8_10 instead of electrs_0_10_6?

[satsfy]

Great point, I made a mistake regarding 0_8_10. I had matched bitcoind pattern, but accidentally reversed the order of the versions. The highest version in bitcoind chain is the lowest, meanwhile I put the highest for electrsd. Latest rebase reverses that order.

EDIT: The problem with v0.10.6 in CI was caused by using the legacy --jsonrpc-import arg after 0.8.10. That nuance was lost on me because execution would fail on my Ubuntu 22.04 for requiring GLIBC 2.38 to test 0.10.6 properly.

[satsfy]

On the latest rebase:

• New electrs feature version cascade: electrs_0_10_6 -> 0_9_11 -> 0_9_1 -> 0_8_10 -> esplora.
• Centralized the version-specific behavior in versions.rs with legible constants USE_LEGACY_COOKIE, USE_JSONRPC_IMPORT, USE_VERBOSE_ARG.
• Esplora is tested with --no-default-features so it does not accidentally combine with the default electrs version.
• no-download job now enables bitcoind_download because it still needs a bitcoind binary while using the system-provided ELECTRS_EXEC.
• Corrected the bitcoind 23_2 feature name in ee9443c (is this correct? Should I have done it in a separate PR)?
• Optional change that I think should be merged: make electrsd CI coverage easier to debug by putting RUST_LOG=debug on electrsd jobs.

[tcharding]

Can we separate the fmt changes from actual code changes in c61ea18

[satsfy]

Latest rebase:

• Split rustfmt cleanup (17866ee), lint error fixes (33158b2) and new rbmt lint configuration (9143712).
• Fix Cargo.toml link typo (28022c5)
• Simplifies version conditions:
  • Using any in #[cfg(any(feature = "electrs_0_9_1", not(feature = "electrs_0_8_10")))]
  • or crate::versions::IS_ELECTRS_0_8_10.

[satsfy]

Latest rebase updates lockfiles because of upstream changes to fix ci

[tcharding]

Can you explain what you want to achieve with this feature gate please?

[tcharding]

E.g "I want this code block to run for these versions: a, b, c"

[satsfy]

So bitcoind feature gates, which served as a model for making electrsd features, are organized into a chain:

30_2 = ["30_0"]
30_0 = ["29_0"]
...
0_18_1 = ["0_17_2"]
0_17_2 = []

In bitcoind's file client_versions.rs:48, you can find a similar example of this gate:

#[cfg(all(feature = "0_21_2", not(feature = "22_1")))]
pub use corepc_client::{client_sync::v21::*, types::v21 as vtype};

So the pattern is all(X, not(Y)).
Now imagine I want the negation of a particular version. Say, I need not(version X).
I would express that in feature gates as not(all(X, not(Y)))
But you mentioned above its hard to understand what that means and I agree.
So I did not(all(X, not(Y))) = any(not(X), Y) = any(Y, not(X)) (De Morgan's laws) such as in:

#[cfg(any(feature = "electrs_0_9_1", not(feature = "electrs_0_8_10")))]

Would you prefer if I experimented with some less complex ways of solving the problem? I suppose I'd need to break away from the bitcoind solution and design a new feature flag solution. We do things this way to prevent users from enabling 2 flags at the same time, and the program not knowing which to use.

The alternative would be writing an "O(n²)" solution where every flag is checked against every other flag to ensure the same functionality. On a new electrsd version N, the versions file would be incremented in at least N lines of code.

[jamillambert]

Could this check be done in one place, e.g. build.rs and a new feature created like electrs_0_8_10_only then all of the any not feature gates changes can be feature = "electrs_0_8_10_only" etc. The new const bools can also then be removed.

[satsfy]

That's a good solution, I implemented it on the latest force push.

[tcharding]

No need for the last patch mate, we have #571 ready to release that change. I was planning on merging this after that release.

[satsfy]

Rebased removing Cargo.toml typo patch.

[satsfy]

Latest force push implements configuration of version checks in the build file.