Fix action packet injections being delayed until next outgoing UDP packet

[Zirk40]

The game client will build an outgoing UDP packet approximately every 400 ms by calling its encode_packet function. The frame the encode_packet function executes on will be referred to as the "encode packet frame". The core hooks the native encode_packet function so it can process each packet in the client's outgoing packet buffer and trigger any registered events for each packet, allowing all services/addons interested in the packet an opportunity to take action, including blocking the packet and/or injecting their own packets. Once processing the client's outgoing packet buffer is complete, the core will immediately begin processing its internal outgoing packet queue which contains any outgoing packets that were injected since the previous outgoing UDP packet. This involves the same process of triggering events and relevant services/addons are given an opportunity to take action.

The action service is one such service that when triggered will block any native (non-injected) outgoing action packets, and will inject its own action packet after triggering a pre-action event, all of which occurs during the encode packet frame. The problem arises because at present the core schedules all packet injections to occur on the next frame, but since the event for the outgoing action packet (or any outgoing packet) will always trigger exactly on the encode packet frame, any packet injections that are requested will always occur exactly one frame too late to be included in the same UDP packet that contains the triggering outgoing packet.

This commit fixes the problem by having all packet injections occur immediately instead of being scheduled to occur on the next frame. As a result, when the core finishes processing the client's outgoing packet buffer and begins processing its internal outgoing packet queue, the injected action packet will already be present in the queue and thus will be included in the UDP packet that is currently being built. Incoming packet injections are also changed to be immediate for consistency, there is no other motivating reason for that change.

One downside of injecting immediately is it is now possible to become locked during encode_packet. If service/addon A is monitoring for packet B' and will inject packet A' in response, and service/addon B is monitoring for packet A' and will inject packet B' in response, the core will never be able to finish processing its outgoing packet queue.

[CLAassistant]

All committers have signed the CLA.