Remove or Refactor Unused and Obsolete Code Across Codebase

Description

There are several sections in the codebase that appear to be unused, obsolete, or marked for removal. This includes:
Deadline handling in mplex_stream (methods for setting deadlines are present but not used anywhere).
Exception classes in various modules (e.g., libp2p/io/exceptions.py, libp2p/tools/async_service/exceptions.py, libp2p/host/exceptions.py, etc.) that may not be referenced or used in the current implementation.
Potential legacy or dead code, as indicated by TODOs or lack of usage.
A systematic review and cleanup will improve code maintainability and reduce confusion for contributors.

Motivation

Maintainability: Removing dead or obsolete code makes the codebase easier to understand and maintain.
Clarity: Reduces confusion for new contributors and users by ensuring only relevant, active code is present.
Technical Debt: Addressing unused code helps reduce technical debt and the risk of bugs from unmaintained sections.

Current Implementation

• In libp2p/stream_muxer/mplex/mplex_stream.py, methods like set_deadline, set_read_deadline, and set_write_deadline exist but are not used or enforced anywhere in the code.
• Multiple exception classes are defined in files such as:
  • libp2p/io/exceptions.py (e.g., IncompleteReadError, MsgioException, MissingLengthException, etc.)
  • libp2p/tools/async_service/exceptions.py (e.g., ServiceException, LifecycleError, DaemonTaskExit, etc.)
  • libp2p/host/exceptions.py (e.g., HostException, ConnectionFailure, StreamFailure)
  • libp2p/security/secio/exceptions.py (e.g., SecioException, SelfEncryption, PeerMismatchException, etc.)
• There are no clear references or usages for some of these exception classes, suggesting they may be legacy or dead code.
• No explicit TODO comments for removal were found, but the presence of unused code and methods indicates a need for cleanup.

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

Yes

Start by reviewing libp2p/stream_muxer/mplex/mplex_stream.py and the listed exception modules, then search the codebase for references to the named methods and exception classes. Document which symbols are genuinely unused before deciding on removal or refactoring. Done means the cleanup is scoped, justified by usage evidence, and does not leave broken references.