fix(state/statebag): filter frequent & large data from client

[AvarianKnight]

• if we accept these willy-nilly, clients could possibly OOM the server, or do a one-to-many make-shift DoS on larger a server
• the size limits here are kept high to keep compatibility with people who "misuse" state bags
• sane defaults for servers that don't send large data via state bags would be set rateLimiter_stateBagSize_rate 1000 and set rateLimiter_stateBagSize_burst 4000

Goal of this PR

Fix the possible abuse cases for state bags, though this doesn't cover all of them theres already another pr sitting that allows better filtering.

How is this PR achieving the goal

The rate and size of state bags similar to msgServerEvent

This PR applies to the following area(s)

Server

Successfully tested on

Game builds: N/A

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

Fixes #2361

[blattersturm]

Do we have a good outlook on what common data sizes people use are, even in worst-case scenarios? Imposing a total size limit might also help for other scenarios (memory leak spam, e.g.).

The report, of course, rather is an issue with clients submitting data to other clients arbitrarily and it overloading the network layer, for which this fix does appear reasonable.

[AvarianKnight]

Do we have a good outlook on what common data sizes people use are, even in worst-case scenarios? Imposing a total size limit might also help for other scenarios (memory leak spam, e.g.).

The common use case for us with state bags is small data, generally only 100 bytes at maximum, except for some global state usage (which is around 200-500 bytes, which still wouldn't get affected by this).

Would be interesting to know other servers general usage.

[AvarianKnight]

It should also be noted this is more of a mitigation then an actual fix (though this should have these to prevent spammy attacks anyways).

My idea for fixing

1. Revert the default to server-side creation as a default
2. Add a new native to allow for certain state bag names to be created by the client
   A bad name would be something like: AllowClientCreationOfStateBag("key")
3. Assign protobuf definitions to keys so the server can automatically reject any malformed requests for state bags.

[blattersturm]

The third point would be a fairly interesting project for other serialization bits as well - schema validation so there's no 'send an object where a bool is expected'-style replication issues for events that have such an annotation, without having to write manual code validating, while also somehow generating fast validation code.

[FlawwsX]

Revert the default to server-side creation as a default

I wouldn't expect this to get approved because it would probably break a lot of scripts out there, but some sort of configuration option for server owners to control this would be nice.

[AvarianKnight]

Revert the default to server-side creation as a default

I wouldn't expect this to get approved because it would probably break a lot of scripts out there, but some sort of configuration option for server owners to control this would be nice.

When it comes to security vs compat, security should probably be of higher priority.

[AvarianKnight]

FiveM has currently fallen to having most sane defaults behind some 'configuration option' due to maintain compatibility, which means that most of the time the server has to run into the issue before it can actually know that it doesn't have the right default.

This is also very hard to find out for this issue is state bags, as they show as hashes in the timeout log instead of proper packet attribution which was provided here #2141

Changing from server-first creation to client can create all was a massive mistake that I voiced at the time in Discord, but the channels that the conversations were done in were wiped so I can't go back and reference them.

[blattersturm]

FiveM has currently fallen to having most sane defaults behind some 'configuration option' due to maintain compatibility

This is what the eventual goal for the original FXv2 effort was, yes - a large watershed point of a few big compat changes that then, if a server runs only FXv2 resources, would put the server in some 'modern' mode which then could be acted upon in e.g. discovery UI in some way to make it a 'desirable' goal for server owners and resoruce authors to work towards.

It however was difficult to coordinate development work towards these changes, so that never really... happened, also as it was meant to be tied with a larger 'FiveM 2' marketing effort with client-side changes and improvements as well, similar to the Windows 10 -> Windows 11 work, where eventually once the work was done the improvements would be lit up for everyone at once, but important platform work could be tested with scoped previews and people manually following the development repo.

Some sort of 'strict mode' or other scoping could make sense as well however (fx_version being replaced with 'editions' and a server being able to run a minimum 'edition' - though how to make sure behavior like this can be tested even in a lower-edition server?), but this'd need a lot of coordination with the resource/asset developer community (or alternative DevRel stuff) in order to get a large portion of the ecosystem on board.