[FEAT] Outgoing queue flushing

[Ketasaja]

Describe your feature

If the server uses Zap to replicate reliable events to the client including reference to an Instance, then deletes that Instance, there's no guarantee the client will receive that Instance as non-nil, because deletion will replicate before Zap replicates its event triggers. If developers could flush a Zap queue, triggering immediate RemoteEvent:FireClients, they could ensure that the Instance reference exists when received by the client because property writes replicate on the same ordering channel as reliable RemoteEvents.

Developers would be able to flush a queue immediately before deleting important Instances.

Implementation Details

Generate a casing variant of flush_queue(channel) where channel has type of a union of string singleton channel names.

Additional context

While developers can type Instances as optional, this is an awkward solution. The server may use Zap to inform clients that a round has ended, then delete the map. Until the Zap event trigger replicates, other client code won't expect the map to be deleted, even if Zap network callbacks see it's nil.

Channels would complement this. Instead of flushing one queue for all reliable events, only the relevant queues need to be flushed. While channels will allow disabling batching, in this case batching is still desirable most of the time.

I think this could be introduced before channels and still be useful.

[sasial-dev]

Isn't this already covered by the manual_event_loop option?