chore(types): drop redundant macro imports that break CI on Rust 1.92

[mehmetkr-31]

Fixes #234.

Summary

On Rust 1.92 the CI lint command fails on arc-consensus-types:

$ cargo clippy --all-targets --all-features -- -D warnings
error: unused import: `crate::codec::impl_versioned_codec`
  --> crates/types/src/codec/network.rs:26:5
error: unused import: `crate::codec::impl_versioned_codec`
  --> crates/types/src/codec/wal.rs:22:5
error: could not compile `arc-consensus-types` (lib) due to 2 previous errors

main is green today only because rust-toolchain.toml pins 1.91.1. Since the Rust Lint job runs with -D warnings, bumping the toolchain to 1.92 or later turns these into hard CI failures.

Why the imports are redundant

impl_versioned_codec is a macro_rules! macro defined in codec/mod.rs above the pub mod network; and pub mod wal; declarations. Textual macro scoping already puts it in scope for both child modules, so use crate::codec::impl_versioned_codec; never resolved to anything the modules didn't already have. Rust 1.92 is simply the first release whose unused_imports lint reports it.

Removing the two imports leaves the pub(crate) use impl_versioned_codec; re-export in codec/mod.rs with no remaining users, and it warns in turn, so this drops that line as well. Nothing outside the codec module referenced the macro by path.

Net effect is 4 deleted lines and no behaviour change: textual macro scoping is long-stable and version-independent, so impl_versioned_codec! resolves identically on 1.91.1 and on 1.92.

Testing

I do not have the pinned 1.91.1 toolchain available locally, so my verification ran on 1.92.0:

• cargo clippy -p arc-consensus-types --all-targets -- -D warnings — clean (fails on main with the two errors above).
• cargo test -p arc-consensus-types — 192 tests pass.
• cargo fmt --all --check — clean.

CI is the authority for the pinned toolchain, and this PR running against 1.91.1 is the check that matters — if the macro somehow did not resolve without the import, the build would fail outright rather than subtly. Happy to adjust if you would rather keep the imports and silence the lint another way (e.g. an #[allow]), though removing dead lines seemed preferable to carrying an allow for them.

[osr21]

Verified against main before reviewing: impl_versioned_codec is defined at codec/mod.rs:29, above the pub mod network; / pub mod wal; declarations at lines 82–86, so textual macro scoping does put it in scope for both children and the two use statements never resolved to anything new. The toolchain is indeed pinned at 1.91.1, so the "green today, hard-fails on the next toolchain bump" framing is accurate, and filing #234 separately from the fix means the constraint is documented even if this PR's approach were rejected. All 11 macro invocations across the two modules are unaffected. Clean.

One structural note worth a line of code or at least awareness: this change makes declaration order in mod.rs load-bearing. Textual scoping only covers the child modules because macro_rules! impl_versioned_codec sits above pub mod network; and pub mod wal;. Before this PR, the path imports meant a future refactor could reorder mod.rs freely — the pub(crate) use re-export made the macro path-addressable regardless of position. After it, someone alphabetizing the file or hoisting the pub mod block above the macro (both common tidy-ups) gets 11 cannot find macro errors with no obvious cause, since nothing at the use sites hints at the ordering dependence. Two cheap mitigations, either sufficient: a one-line comment above the macro ("must precede the pub mod declarations — child modules rely on textual scope"), or keeping the pub(crate) use and switching the 11 invocation sites to nothing at all — they already work — while documenting why. I'd take the comment; it's the only part of this ordering contract that's currently invisible.

On the 1.92-only local verification: the reasoning holds and is worth spelling out for the record — the failure mode if textual scoping didn't cover the modules is a compile error at the 11 invocation sites, not a silent behavior change, so this PR's own CI run on the pinned 1.91.1 is a complete check. Macro resolution here has been stable since pub(crate) use macro re-exports landed in 2018-edition Rust; there is no version in between where the removal compiles but resolves differently.

Removing dead lines over #[allow]-ing them is the right instinct — an allow would have carried the lint suppression forever to preserve imports whose only function was making order not matter, which is better achieved with the one-line comment.

Approving; with the ordering comment added this is a complete, future-proof close of #234.