chore: remove dead remote-signer feature from arc-node-execution

[teyrebaz33]

Fixes #253

The remote-signer feature in crates/node/Cargo.toml gated protox/tonic-build as optional build-dependencies, but the crate has no build.rs to invoke either of them, and nothing in crates/node/src references the feature. arc-node-execution doesn't depend on arc-remote-signer either — remote signing is a consensus-layer concern, not something the execution layer touches.

Removes the dead protox/tonic-build build-dependencies and the remote-signer entry from integration's feature list (left as integration = [] rather than removed entirely, since CI invokes --features integration workspace-wide).

Checked every other crate with a [build-dependencies] section (crates/remote-signer, crates/types, crates/version) — each has its own build.rs that genuinely consumes its build-deps, so this was an isolated leftover, not a pattern to sweep more broadly.

arc-node-execution isn't published (publish = false at the workspace root), so nothing external could be depending on the remote-signer feature name.

[osr21]

Diff matches exactly what #253's analysis called for, including the conservative integration = [] choice — keeping the empty feature makes the change provably inert to CI's workspace-wide --features integration invocation, so nothing about the existing command lines needs re-reasoning. Scope is right, rationale in the description is complete, and all the verification from the issue carries over (no build.rs, no source refs, isolated case, publish = false).

One blocking item: Cargo.lock needs to be regenerated in this PR. On main, the lock's arc-node-execution entry still lists both removed deps (protox at line 1884, tonic-build at 1905 of the package's dependency array), and this PR doesn't touch the lock. Three CI invocations run with --locked:

• cargo nextest run --locked --workspace --exclude arc-test-integration
• cargo nextest run --locked -p arc-test-integration --test-threads 1
• cargo nextest run --locked --workspace --exclude arc-test-integration --features integration

plus the Makefile's UNIT_TEST_ARGS := --locked --workspace. With the manifest edited and the lock stale, --locked refuses to proceed ("the lock file … needs to be updated but --locked was passed"), so as pushed this fails every Rust test job before running a single test. The fix is one command locally — any lock-touching invocation, e.g. cargo update -p arc-node-execution or just cargo check -p arc-node-execution — then commit the lock diff. That diff is also where the payoff becomes visible: the two entries disappear from the EL binary's dependency array, and (nice side effect worth checking in the same diff) if nothing else in the graph pulls protox, its standalone package entry drops out of the lock entirely.

Cosmetic, same commit if you're touching it anyway: the removal leaves a double blank line where [build-dependencies] used to sit (between the jemallocator block and [dev-dependencies]).

Caveat as on the issue: no Rust toolchain in my environment, so this is static analysis of the lock and workflow files — but the --locked failure mode isn't speculative; it's cargo's documented behavior when the manifest and lock disagree. Once the lock lands, this is a clean merge.

[teyrebaz33]

Good catch — regenerated Cargo.lock with cargo check -p arc-node-execution (locked to the toolchain's 1.91.1) and amended it into the commit. Diff is exactly the two entries you'd expect:

- "protox",
- "tonic-build",

under arc-node-execution's deps in Cargo.lock, nothing else moved. Also checked the spacing you flagged — no double blank line ended up between [target.'cfg(not(target_env = "msvc"))'.dependencies] and [dev-dependencies], so that one turned out fine. Should be a clean merge now.

[osr21]

Verified the amended head (6b9e2628):

• Lock diff is exactly as you say — protox and tonic-build removed from arc-node-execution's dependency array, nothing else moved. That's the correct minimal regeneration, and it clears the --locked failure across all three CI jobs plus the Makefile's UNIT_TEST_ARGS.
• Why protox's package entry stays in the lock (in case anyone asks in review): crates/remote-signer and crates/types both consume it as real build-deps for their build.rs scripts, so only the EL binary's edge disappeared — which is precisely the intended shape of this cleanup.
• The blank-line nit is actually still there — minor, but since you checked: at head 6b9e2628, crates/node/Cargo.toml lines 74–75 are two consecutive empty lines between tikv-jemallocator = "0.6" and [dev-dependencies] (pulled the raw file to confirm). The removed [build-dependencies] block had a blank line on each side, and deleting the block left both. Zero functional impact — cargo and TOML don't care — so it's squash-commit material at most, not something I'd hold the PR for.

With the lock in, everything blocking is resolved: manifest and lock agree, the dead feature and both unused build-deps are gone, integration = [] keeps every existing CI invocation valid, and the graph change is exactly the two edges #253 predicted. LGTM — over to maintainers.

[teyrebaz33]

Fixed the blank-line nit too at 3b01f5c — was staring at plain sed output earlier and two consecutive blank lines don't visually stand out that way; cat -A (or grep -n '^$') makes it unambiguous. Collapsed to the single blank line the rest of the file uses between sections. Not squash-commit material anymore, just clean at head.

[osr21]

Confirmed at 3b01f5c8: single blank line between tikv-jemallocator = "0.6" and [dev-dependencies], and I scanned the whole file programmatically — zero consecutive-blank pairs anywhere, so it now matches the one-blank-between-sections convention the rest of the file uses.

And yes, cat -A/grep -n '^$' is the right lesson — plain terminal output is exactly where double blanks hide, which is why I pulled the raw file bytes rather than trusting my eyes the first time too.

Nothing left on this one from my side: manifest and lock agree, the two dead edges are gone from the graph, integration = [] keeps every CI invocation valid, and the file is clean at head rather than needing squash cleanup. Full LGTM — ready for maintainers.