Address Impact of Frequent Deprecations and MSRV Increases

Description

Recent versions of rust-libp2p have introduced significant breaking changes and deprecated core features, alongside frequent increases in the Minimum Supported Rust Version (MSRV). While continuous development and improvement are expected, the pace and nature of these changes, as seen in the CHANGELOGs (e.g., libp2p/CHANGELOG.md), pose challenges for users trying to maintain compatibility and upgrade their dependencies. Specific examples include the removal of Transport::with_bandwidth_logging, SwarmBuilder::with_bandwidth_logging, and TransportExt in 0.56.0, the removal of the mplex module, and MSRV bumps from 1.65 to 1.73 to 1.83.0 in relatively short periods.

Motivation

The current approach can lead to:

• Difficulty for users in upgrading dependencies due to unexpected breaking changes and removed features.
• Increased maintenance burden for downstream projects that need to constantly adapt to API changes and MSRV requirements.
• Potential for users to remain on older, unsupported versions to avoid migration complexities.
• Fragmentation within the ecosystem if users cannot keep up with the required Rust versions.

Addressing this issue is crucial for fostering a stable and accessible library that encourages broad adoption and reduces friction for contributors and users alike.

Current Implementation

The changes and deprecations are documented in the CHANGELOG.md files across the various crates (e.g., rust-libp2p/libp2p/CHANGELOG.md). The deprecated features have been removed or replaced, and the MSRV is enforced based on the Cargo.toml settings and CI. The current implementation requires users to make potentially significant code modifications and upgrade their Rust toolchains when updating to newer rust-libp2p versions.

Are you planning to do it yourself in a pull request?

Yes

Start by reviewing the relevant libp2p/CHANGELOG.md files, the crates' Cargo.toml settings, and the CI configuration that enforces MSRV. Compare the cited removals and version increases with the current upgrade process, then define a concrete, agreed-upon change that reduces upgrade friction and document how completion will be verified.