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.