Addition of QUIC networking primitives

[TirushOne]

Objective

Add networking capibilities to bevy and create a structural fundation in the code base for further netcode in the future.

Solution

Reimpliment/wrap Quinn types to use bevy's async runtime.

Quinn is a pure rust implimentation of the QUIC protocol. QUIC is a modern transport protocol addressing shortcomings of TCP, such as head-of-line blocking, poor security, slow handshakes, and inefficient congestion control.
QUIC also allows for low latency communication using datagrams, while maintaining encryption. In short, QUIC allows for the best of both TCP and UDP in one protocol, making it a stella start for anything networking related you might be creating.

It will only compile for paltforms that support std. For web applications, there are some protocols out there, but implimenting them with a consistent api between web applications and native ones would be more chellenging. So I think something battle tested, and with a stable api, like Quinn, is a better place to start.

Testing

Extensive testing shouldn't be needed, as most of the origonal code in this pr is tested through the example, and everything else is just very thin wrapping types and funtions.

---

Changelog

Added

• 'quic' feature flag, exposing async QUIC networking primitives.

• 'tls' feature flag, enables rustls as a dependancy for use with the QUIC protocol (and other encrypted protocols in the future).
  Both are off by default.

• QUIC networking primitives, backed by quinn.

• A new example under "networking" showing how to use QUIC to send datagrams.

• Added a new crate "bevy_net" as a place for all future networking-related code.

Notes

The quic implimentation in this pr is based on the Quinn crate. Will working on wrapping quinn I found a bug where a couple of types quinn uses weren't rexported and so you could used the funtion associated with them. For that reason I didn't include those function. A made a pr to fix the issue and it has been merged, and a update which fixes the issue, and has other content, should be out, as of time of writing, "in about a week". So that reimplimenting the relivant methods and updating Quinn as a dependancy as soon as the update is out is very much a "todo" and I have left a comment in code that says much the same.

[Shatur]

For networking I think it's better to start as a third-party crate, this will make the development much faster and more users will be able to try it.
We also have https://github.com/Henauxg/bevy_quinnet.

[TirushOne]

For networking I think it's better to start as a third-party crate, this will make the development much faster and more users will be able to try it. We also have https://github.com/Henauxg/bevy_quinnet.

I don't think any of this is wrong, but I also don't see why it couldn't come boundled with the base engine. For the users who want to not make a networked game, it doesn't effect them because the feature is off by default, and the amount of time contributers spend maintaining it should be very low (out side of some initial bug fixes maybe). Or in other words there isn't really any development left to do on this spesificley. Because most users don't want to make a networked game, for those who do they are going to have to go searching and maybe or may not find a decent implimentation. Outside of networking stuff (and an offical editer) the only other thing bevy lacks is a phyisics engine, but rapier is well known enough that if you go searching for one, you'll find it easily, and it is popular enough to have it's own set of contributers maintaining it without needing to be fostered in the main repo.

Also if we already have a meshlet render (which btw I think we did that before unity) having some basic networking primitves doesn't seem like a lot to ask for.

[Shatur]

but I also don't see why it couldn't come boundled with the base engine.

Networking is an area where there is no solution that fits all use cases.
Also it's much faster to iterate as a third-party crate. Take a look at crates like https://github.com/lucaspoffo/renet or https://github.com/Henauxg/bevy_quinnet, both still have the development going. It's better to upstream something already adopted if upstream at all.

for those who do they are going to have to go searching and maybe or may not find a decent implimentation

It's not a problem. I think where Bevy shines is in its ecosystem. It's very easy to find any of the mentioned crates, and they are both good.

[TirushOne]

It's not a problem. I think where Bevy shines is in its ecosystem. It's very easy to find any of the mentioned crates, and they are both good.

Where do you think the distinction is then? When does something deserve a first party implimentation and when doesn't it?

[Shatur]

If something can be implemented as a third-party crate, it's better to do so. This way, you can achieve better iteration speed and have it tested by many users before upstreaming.

[NiseVoid]

Where do you think the distinction is then? When does something deserve a first party implimentation and when doesn't it?

Usually things are added as a first party feature once the solution has either become very standardized and non-controversial, or there is a huge benefit to offering a first-party solution so things become more interoperable between bevy, third-party crates and user code. I don't think either of these is the case here. For a first party solutions there are also some concerns regarding web support, which could be solved by making it based on WebTransport (which is based on HTTP3, which is based on QUIC), but afaict the crates in this area aren't very well developed and they often have massive dep trees which would really harm compile times 🤔

[alice-i-cecile]

Agreed with the above. Closing this out, but as the ecosystem converges and matures I'm open to adopting a networking solution.