State deltas for game updates of players and projectiles

[AminArria]

Warning

Needs to be merged with https://github.com/lambdaclass/champions_of_mirra/pull/2084

Motivation

Part of #494

Summary of changes

• Update protobuf
  • Mark fields that we are going to delta as optional, this allows to check if there are set or not. Otherwise default value for the type is implied (e.g. 0 for integers)
  • Modify vertices to support deltas
  • Add UNDEFINED enums to use as null value
• Created diff/2 to receive any 2 terms and output the resulting delta, check the code for a more thorough explanation and edge cases
• Modify creation of update message to handle all cases where something could be nil due to the result of diffing
• Send deltas for obstacles, bushes, and crates. This 3 things represented more than 80% of the delta reduction that we could expect to achieve
• game_client is broken due to this change. Fixing it should be a follow up to this

How to test it?

Test with this client branch https://github.com/lambdaclass/champions_of_mirra/pull/2084

To test play as usual

We should be doing some load tests and profiling in apps to compare against not doing deltas

Checklist

• Tested the changes locally.
• Reviewed the changes on GitHub, line by line.
• This change requires new documentation.
  • Documentation has been added/updated.

[AminArria]

This is an interesting change that is needed for diffing lists under a specific scenario, otherwise its a near impossible task. So the scenarios

• If new_list is different than old_list (meaning not an exact match) the resulting delta is new_list
• If new_list is exactly the same as old_list the resulting delta is nil (no delta)

To allow for that second scenario we would have needed a sort of optional repeated field in protobuf, but this is not supported. So the second best thing is this solution where we wrap the list in another message. This wrapper becomes optional and the inner only have the repeated field

[AminArria]

This new enum value PROJECTILE_STATUS_UNDEFINED and the similar one in CrateStatus is a protobuf best practice cause it been the 0 value will serve as the default for the enum. You are not supposed to actually have business logic tied to it, for example I only use it in the client as a null check

Additionally you probably noticed that its called PROJECTILE_STATUS_UNDEFINED rather than UNDEFINED that's cause the protobuf C# compiler didn't like 2 enums with a value named the same 🤷‍♂️

[agustinesco]

LGTM!