chore(transport): remove module_name_repetitions

[mxinden]

We allow the clippy lint module_name_repetitions:

neqo/neqo-transport/src/lib.rs

Line 7 in a758177

#![allow(clippy::module_name_repetitions)] // This lint doesn't work here.

We e.g. prefix various types in the ecn module with Ecn:

neqo/neqo-transport/src/ecn.rs

Lines 18 to 30 in 3001a3a

	/// The number of packets to use for testing a path for ECN capability.
	pub const ECN_TEST_COUNT: usize = 10;
	/// The number of packets to use for testing a path for ECN capability when exchanging
	/// Initials during the handshake. This is a lower number than [`ECN_TEST_COUNT`] to avoid
	/// unnecessarily delaying the handshake; we would otherwise double the PTO [`ECN_TEST_COUNT`]
	/// times.
	const ECN_TEST_COUNT_INITIAL_PHASE: usize = 3;
	/// The state information related to testing a path for ECN capability.
	/// See RFC9000, Appendix A.4.
	#[derive(Debug, PartialEq, Clone, Copy)]
	enum EcnValidationState {

As discussed in #2270 (comment), I suggest removing the allow and instead fix the module name repetition.

[mansf-osk]

I'll start working on this! Are there any places where we don't want to get rid of the module name repetitions? As far as I can see we allow them in a lot of modules, just going by this quick search.

Maybe it makes sense to remove the crate-wide allow attributes (as the one referenced above) and leave be or possibly add local allow's where it makes sense to keep the module name repetitions?

[mxinden]

@mansf-osk I suggest starting with a single module, e.g. neqo-transport/src/ecn.rs.

Small pull requests reduce the likelihood of merge conflicts and make reviewing easier.

Maybe it makes sense to remove the crate-wide allow attributes (as the one referenced above) and leave be or possibly add local allow's where it makes sense to keep the module name repetitions?

Happy for the crate-wide #![allow(clippy::module_name_repetitions)] to be replaced by the missing local allows with the first pull request.

[larseggert]

Just so I understand, we would rename e.g. EcnInfo to Ecn::Info, i.e. prefix with the module name? (Because otherwise Info is a bit generic.)

[mxinden]

It would be defined as:

// neqo-transport/src/ecn.rs

pub struct Info {
  // ...
}

and it would be used as:

// Some other file.

use ecn;

fn my_func() {
  let ecn_info = ecn::Info::new();
}

Just like in the standard library where it is std::io::Error and not std::io::IoError.

Does that make sense @larseggert?