Rely on ECS to store ClientEntities, Connections, etc.

[cBournhonesque]

Currently we store a lot of the lightyear internals in resources:

• ClientConnection contains the underlying NetClient (either Local, Netcode or Steam)
• ConnectionManager contains the main resource to send/receive messages
• ServerConnections contains a vec of ServerConnection which are NetServers(either Netcode or Steam)
• we have one entity per client that contains ControlledEntities
• we have ServerConnectionManager which contains a hashmap from ClientId->Connection, to send/receive messages

It's a bit awkward to access some of the information, in particular access information relative to a given ServerConnection.

Would there be benefits to move more stuff into entities/components instead of resources?
i.e. a design closer to aeronet

Design

• we would have a ServerEntity per 'type' of server (Steam, Netcode::WebTransport, Netcode::WebSocket, etc.)
• we would still need a global overarching resource that maybe provides the index from ClientId -> ClientEntity.
• some of the parameters would also be global (input-delay, etc.)
• the ClientEntity on the server could contain ControlledEntities, but also all the info related to the connection itself, the Transport, the BufferedMessages, etc. It would have a parent that is the Server that is used for communication

How would users send/receive messages? i.e. what is the user-facing API?

• Client: query the entity that contains the transport, and use that?
• Server: we would still need a way to find the correct server-entity to use given a client-id

Maybe the message-sending receive should be a Command?
PROS

• the systems that write messages can run in parallel because they don't need ResMut<ConnectionManager> anymore
• no need to store the message_registry inside ConnectionManager anymore, it can be fetched inside the Command
• inside the command we can fetch the correct Transport entity for the message
• can also separate stuff like ReplicationRceiver into a Component
  CONS
• then the user cannot the handle the error immediately though...

commands.send_message_to_target<C: CHannel, M: Message>(message: &M, target: NetworkTarget)

inside the command
- fetch the MessageRegistry, GlobalServer (which holds a writer and the ClientId<>ClientEntity mapping)
- if no entity-mapping, use the global server's writer to serialize to bytes, then for each ClientEntity (that has a Transport), buffer the bytes
- if entity mapping, each ClientEntity's Transport/Writer does the serialization

Components:

// used to send/receive raw bytes
Io {
   local_addr: SocketAddr,
   sender,
   receiver,
   state,
   stats
}
Create a SteamIoSender/SteamIoReceiver that fallback on using the steam client.


// used to send/receive messages on top of an io
// adds reliability/ordering/fragmentation/stats/channels
Transport {

}

// Maybe split into NetClient and NetServer
// adds the concept of a long-lived session, with disconnection/connection
// It has send / receive methods that take &mut Io as input?
// or should Connection contain the Io?
Connection {

}