[Enhancement]: Protocols need to send additional packets after the RMC response

[ashquarky]

Checked Existing

• I have checked the repository for duplicate issues.

What enhancement would you like to see?

Various protocols generate additional traffic outside the basic RMC request-response model, but nex-protocols-go does not provide enough control over ordering to implement this fully.

For example, take matchmaking and its participation notifications:

(Capture from Minecraft: Wii U Edition on Nintendo Network)

Note how the RMC Success response is delivered first, then the notification events relevant to the joined match. The PRUDP sequence numbers also reflect this ordering.

Under the current design of nex-protocols-go, this isn't possible to emulate, since the protocol implementation only gets to return a single RMC response, and globals.Respond will only ever emit a single PRUDP packet.

nex-protocols-go/matchmake-extension/join_matchmake_session_with_param.go

Lines 40 to 46 in a9e527b

	rmcMessage, rmcError := protocol.JoinMatchmakeSessionWithParam(nil, packet, callID, joinMatchmakeSessionParam)
	if rmcError != nil {
	globals.RespondError(packet, ProtocolID, rmcError)
	return
	}
	globals.Respond(packet, rmcMessage)

Currently this is worked around by emitting the notifications inside the protocol implementation itself, but this results in the wrong ordering.

Any other details to share? (OPTIONAL)

Some ideas for improving this:

1. Add an events system, like the existing emit("data") stuff in nex-go, to either PacketInterface or a new "call context" struct containing PacketInterface, then add an OnAfterResponse event. The protocol implementation could then register a lambda function to finish up any additional work it wants to do after the RMC response is sent (like notification delivery). This feels like a neat solution since all notification delivery can be handled together after matchmaking is "done".
2. Allow multiple packets to be returned from the protocol implementation, which are then all sent by nex-protocols-go. This is a slightly messier solution for notifications in particular since, in addition to the notifications to the caller described here, there's also notifications going to other unrelated clients too which would need separate handling. Would allow for bundling with the RMC response, though.