Reject BSATN function args where the buffer is too long

[gefjon]

Description of Changes

Fixes #4945 .

BSATN parsing generally accepts the case where there are unused trailing bytes in a buffer after parsing a type. This allows both building up compound-typed objects by repeatedly parsing their members, and packing multiple values into the same buffer sequentially.

However, it has an unfortunate consequence when parsing untrusted inputs: if a client submits an input e.g. for a reducer call which is not of the expected type, but has a prefix that parses at the expected type, a direct use of the BSATN parser will accept it and silently ignore the suffix. One simple example is a client attempting to submit an i64 when SpacetimeDB expects an i32, resulting in the high 4 bytes of the client submission being ignored, potentially resulting in a different number being parsed than the one submitted.

In this commit, we check when parsing user-submitted function arguments that not only did the parse succeed, but that it also consumed the entire input. If the entire input was not consumed, we treat it as an error in the class described above.

API and ABI breaking changes

I'm not sure "ABI break" is technically the correct label, but this is from a certain perspective a breaking change to the raw WebSocket API, in the sense that we now reject some requests that previously we would accept.

Expected complexity level and risk

2: possible some user somewhere has been relying on this behavior and sending unused bytes in the arguments part of a CallReducer or CallProcedure message somehow. Most likely this would be a user of the raw WebSocket format, but it could also be someone with outdated generated bindings in a benign way.

Testing

• Added a unit test.
• Manually build a client with incorrect bindings for a reducer's arguments in the way described above and encounter the new error.