Release 0.9.0

Added

Bandwidth management and priority scores

Lightyear now supports putting a limit on the bandwidth between a client and a server.
You can set a cap (for example 50KB/sec).

If there are too many messages to send, lightyear will use a priority with accumulation scheme to decide which messages will be sent and which will be discarded. You can set a priority score on each message, channel or entity to define its relative priority to other messages.

You can find more information in the book.
You can also check an example online

Added traits to represent the long-running connection

We already have a trait Transport that represents how to send raw byte slices over the wire, with several implementations: UdpSocket, WebTransport, WebSocket, etc. An Io is a wrapper around a dyn Transport, which lets us swap the different transport implementations effortlessly.

Similarly, I am introduce two new traits NetClient and NetServer that are an abstraction of a long-lived 'Connection': how to connect, do a handshake, get the list of connected clients, disconnect, etc.
The structs ClientConnection and ServerConnection becomes wrapped around dyn NetClient and dyn NetServer, so that we can use different 'connection' implementations. The only implementation currently is based on the netcode protocol, but this opens the door to other connection abstractions. In particular I plan to use this to add steam sockets support!

Added support for WebSockets (from @Nul-led )

There is one new implementation of the Transport trait using websockets! Those work on both native and wasm; they can be a good alternative to WebTransport on browsers that don't support WebTransport (Safari). They can be easier to work with as well as there is no need to generate a short-lived certificate.
Be mindful that websockets use TCP and can encounter head-of-line blocking.

Fixed

• Some bugfixes related to pre-spawning entities
• The io connection (WebTransport, UDP socket, etc.) establishes the connection when the connect function is called instead of when the lightyear Plugins are built
• Removed the Eq bound on non-leafwing inputs, so that they can contain f32s

Migration

• See this PR for how the creation of the Client and Server plugins need to be updated. They don't take as input an Io struct anymore, instead the NetConfig has an inner field IoConfig which defines how the Io will be constructed.
• There is no need to have a tokio runtime anymore, all the async code now gets executed on the IoTaskPool provided by bevy! Take a look at https://github.com/cBournhonesque/lightyear/pull/141/files#diff-7baf4299a3291e8534a70ffcfa2eec44e80942e6525445b2222204d1100dde42L101 to see how to update the main entrypoint function.