chore: Bump Zstd.Sharp from 0.8.5 to 0.8.8

[bparks13]

What's Changed

Bump the Zstd.Sharp package from 0.8.5 to 0.8.8. The main reason for this bump is to bring that project's dependency System.Memory up to v4.6.0, and is implemented in this PR.

I implemented this change in Zstd.Sharp to fix a version mismatch issue; I am working on a plugin for use in Bonsai-Rx, which does not allow me to have an assembly binding redirect, leading to a run-time exception due to multiple System.Memory versions present.

All tests passed locally, and all builds succeeded.

[adamreeve]

I'm generally not keen to require very recent versions of dependencies, as that can cause issues for users that need an older version for whatever reason. The current dependency on version 0.8.5 is treated as a lower bound by NuGet, so users should be able to specify a more recent version in their package references. Does Bonsai-Rx's plugin model also prevent you from adding a dependency on a newer version of Zstd.Sharp?

[CurtHagenlocher]

It's a bit hard to justify picking a specific dependency to accommodate a particular downstream consumer because what do we do if there's a different downstream consumer who needs a different version of the same dependency?

That said, it seems like the "backfill" assemblies like System.Buffers, System.Memory and System.ValueTuple have stabilized again and haven't been changed in a year or so.

[adamreeve]

The changes in Zstd.Sharp between 0.8.5 and 0.8.8 also look fairly minor from a quick glance, so I'm not strongly against merging this if it really is required for this use case.

[bparks13]

@CurtHagenlocher @adamreeve Thanks for the comments, I appreciate the perspective here.

Unfortunately, in this case I’m not able to add a dependency on a newer version of ZstdSharp. The Bonsai plugin model uses a custom dependency resolver that requires strongly-typed assembly versions to match exactly. Because of that, a mismatch between System.Memory v4.5.5 and v4.6.0 results in a runtime exception when compression is used, which is not something that can be resolved by the plugin model (e.g., via binding redirects or version overrides).

I definitely understand the concern about not catering to a specific downstream consumer. My thinking with this change is that it primarily brings ZstdSharp in line with the System.Memory version used in this repo. The changes between v0.8.5 and v0.8.8 do appear to be minimal. Given System.Memory and related packages have been stable for a while, this felt like a relatively low-risk way to avoid runtime issues that would otherwise be difficult to overcome.

Happy to discuss this further, I want to make sure this is the right decision.