Use msgpack for API

[nezuo]

Fixes #363.
Fixes #881.

Remaining Tasks

• Test more extensively.
• Use msgpack for write api request.
• Handle NaN inside of patch compute.

[nezuo]

patch_compute.rs will treat NaN properties as always changed. This means that you will see nan property changes in the rojo plugin UI (when nothing actually changed).

I'm not sure what's the best way to go about fixing this. Ideally we also account for it types that have multiple numbers like CFrame or NumberSequence.

[nezuo]

I just pushed a commit to account for NaN values. It's a lot of complexity just to handle NaN (and hopefully we don't forget to update it with any new variants because Variant is non_exhaustive). I'm not really sold on the approach, but I'd like to hear anyone's thoughts on it.

[Dekkonot]

This whole trait is... not ideal. I would strongly prefer we move the equality check for Variant to its own file, and make it a simple function instead of a trait.

I have a function already implemented in my syncback fork here if you want to steal it.

It does require us to pull in float_cmp as a crate, but I think that's fine.

[nezuo]

I'm now using the variant_eq function from your fork. I did change the the Attributes comparison to simplify it if you want to check that out.

[Dekkonot]

This still has the added Different trait despite it not being used for anything anymore. It should be removed.

[nezuo]

That's my bad, I thought I removed it.

[Dekkonot]

I see no obvious problems with this change, but I'm scared of deploying it since it's not battle tested. msgpack-luau is reasonably well tested and used by Argon so I trust it, but I still worry.

@kennethloeffler What do you think?

[Dekkonot]

This could probably stand to be made more robust rather than special-casing png files, but I'm also willing to push that off into a different PR since this is primarily plugin-facing.

[kennethloeffler]

Because we have urgent changes in the pipeline (namely, support for the new Content datatype), and already have several changes of large surface area in both Rojo and its backing libraries, this change is too risky to include in Rojo 7.5. We'll definitely want to get this in after we're done there though.

The big thing we'll have to tackle here is more comprehensive testing. I'd looove to have automated tests for this - it's probably something we can feasibly accomplish with Lune!

[boatbomber]

I would like to revisit this after #1142 merges- as we're already doing a breaking change protocol version bump, it may be good to include this improvement as well

[nezuo]

Closing in favor of #1176.