[FEAT] Channels

[jackhexed]

Describe your feature

Currently zap batches all reliable events together, and doesn't batch unreliables at all. This behavior can be undesirable in both cases, as batched reliables aren't ordered with the rest of Roblox's replication, and unbatched unreliables can use more bandwidth than expected.

Adding channels would enable users to specify what events are batched together, if they're batched at all. We can also enable users to decide exactly how many events are batched into one call, and how often zap should empty the queue.

This increased control of what events are batched enables zap to staticly verify that a batch of the maximum size can be sent with unreliables and won't be dropped.

channel A = {
	type: Reliable,
	batch: {
		size: 10, -- maximum of 10 events per batch
		time: 1, -- maxiumum of 1 second in between each send
	},
	-- if queue isn't specified the queue type is `event(64)`
}

channel B = {
	type: Unreliable,
	-- if batch isn't specified the events are unbatched
	queue: frames(10), -- 10 frames before remote is connected to
}

event Uses_A = {
	channel: A,
	from: Client,
	call: SingleAsync,
}

event Uses_B = {
	channel: B,
	from: Client,
	call: SingleAsync,
}

event Uses_B_Again = {
	channel: B,
	from: Client,
	call: SingleAsync,
}

The syntax allows for channels to specify their reliability type and batching. Events specify their channel with the new channel field. As channels are now specifying the type, events no longer specify their type field. Please note that all of these events are dataless events, but that is not a requirement with channels.

As queues are now specified by channel, the queue-related options will be removed.

Due to events no longer specifying their type, two channels should be included by default: Reliable and Unreliable. These channels use their respective reliability types, have an event(64) queue type, and have no batching. For almost all users these channels will be sufficient.

In the future when namespaces are added, channel declarations will behave the same as type declarations with namespaces.

Alternatives

We could make multiple different types to go in the type field for events and add a batch field, but this feels very weak from a user standpoint, and doesn't offer much from a performance standpoint.

Implementation Details

Each channel should create it's own remote, and it's own connections. If a channel has batching enabled it will have a stored outgoing queue. Channels should have separate event Ids, this way we can reuse Ids and potentially stay under the 256 limit.