Fix memory leak between the RLBot library and rlbot-rust

[saintdev]

BREAKING CHANGE

Fixes #25 a memory leak where the byte buffer passed from the RLBot interface library was never freed. This requires quite drastic internal change to how serialized flatbuffers are handled. Because it is now required to deserialize into our own types, this will break existing Rust bots.

Concerns

• The need to immediately deserialize to our own types will break existing bots.
• There is an extra memory allocation and copy, so we can immediately free the ByteBuffer passed from the RLBot library.
• External types src/game.rs
  • Can easily desync from their upstream ffi and flatbuffer types (src/ffi.rs and src/rlbot_generated.rs)
    • Can this be automated?
  • Are manually defined, instead of being derived from an upstream source.

I'm also open to rewriting this with a flatbuffer wrapper type that Deref's to the underlying flatbuffer type. I discarded this solution, because it means the wrapper has to carry around a reference to RLBotCoreInterface::free(). Overall, the current solution seems cleaner, at the expense of an allocation and a copy.

[kipje13]

I'm also open to rewriting this with a flatbuffer wrapper type that Deref's to the underlying flatbuffer type. I discarded this solution, because it means the wrapper has to carry around a reference to RLBotCoreInterface::free().

Would it be possible to copy the flatbuffer data into a vector that is owned by the wrapper? It should then be possible to immediately free the original buffer so you don't have to carry around a reference to RLBotCoreInterface::free(). This has the same downside that you need allocate and copy some memory. But on the other hand it will only require slight changes to existing bots and does not require manual updates when the flatbuffers schemas are updated.

[Quetzal2]

Nice!
I agree, maintaining the types manually is a bit annoying, and Kipje's take on it looks very interesting.
I'm ok to go with this version first to fix the leak. We can always roll out an improved version later on. And I don't think that porting the existing bots once again will be a big task (there's not a lot of bots using it at the moment either), so there's no special constraints concerning a future improved version, if we want one.