feat(quinn,quinn-udp): Introduce net feature to allow disabling socket2 and std::net::UdpSocket dependencies

[matheus23]

Changes

• Adds a default-enabled net feature to quinn-udp and quinn
• Marks socket2 dependency as optional (only enabled with net feature)
• Code depending on std::net::UdpSocket (e.g. Runtime::wrap_udp_socket or Endpoint::rebind) becomes gated by net feature
• Added web_time dependency to quinn-udp and quinn that is only enabled in wasm32-unknown-unknown target

Note: The net feature will be implied by current runtime-* features.

Testing

• These changes were verified outside this PR with a custom Runtime implementation in the browser and nodejs.
  I'm not contributing this test (yet?) as discussed.
• The "test (wasm32-unknown-unknown)" github action job was adjusted with a check making sure there's no (import "env" ...) in the quinn .wasm file when built.
  This is a good, even if not quite sufficient effort in making sure the Wasm build doesn't break.

[matheus23]

I realized this PR is missing some rationale, so I'm writing this on the top level for better visibility:

Does it still make sense to depend on quinn-udp in the WASM world?

This was one of the first things I was thinking initially, too.

The only definitions that quinn without the net feature needs from quinn-udp now are BATCH_SIZE, RecvMeta, EcnCodepoint and Transmit.

The fundamental problem IMO is that AsyncUdpSocket is tied to quinn and its Runtime, but then AsyncUdpSocket depends on e.g. RecvMeta. quinn-udp and quinn are thus tightly coupled at the moment.

The solution would be to separate out the type definitions of RecvMeta, etc. into another crate that both quinn-udp and quinn depend on. I didn't want to do this as that's quite an invasive refactor.
It is not possible to move RecvMeta etc. to quinn, because then quinn-udp would like to depend on quinn and the other way around.

Are you still using the Runtime trait in your WASM setup?

Yes, there's no way of using quinn without providing a Runtime (e.g. the Endpoint keeps a reference to it).

The alternative would be integrating with quinn-proto only, which basically means reimplementing quinns connection and endpoint drivers, timers, API, etc. That's practically not an option.

[djc]

Okay, I think this all makes sense. Thanks!

[djc]

@Ralith ping?

[mxinden]

I understand the rational above for importing quinn-udp in a WASM context.

That said, for what my opinion is worth here, I can't judge whether it is worth the complexity it introduces. Will defer to the actual Quinn maintainers.

[mxinden]

Instead of the many cfg(feature = "net"), wouldn't something along the following be simpler?

#[cfg(feature = "net")]
use net::*;

#[cfg(feature = "net")]
mod net {
  // Everything that was previously feature flagged behind net.
}

[matheus23]

I've got a version where I've experimented with that.
It's a much more invasive change, I'm not sure if it's much better?
I can add it to this PR if other people agree: n0-computer@d06b71b

[mxinden]

Thanks for the commit. I didn't think of the fact that unix.rs and windows.rs would need to be under the net/ module.

At this point I don't have a better idea, nor a preference for the options listed here.

[RealAstolfo]

couldnt windows and unix stuff be stuffed under a "system" "sys" or something like that.

[Ralith]

You mentioned that you also considered gating on target instead of a cargo feature. Can you elaborate on why you went with the feature instead? I think exposing a subset API on some targets is less hazardous than a cargo feature, particularly as this is technically a semver break affecting users who have default-features = false and use only a custom runtime.