feat!: Rework schema compatibility

[Kriskras99]

I think this is better overall, but I can understand if you would want to revert the Compatibility::Partial and keep exactly to old behavior.

This new implementation is (in my opinion) simpler than the previous iteration and easier to modify when needed.

I've introduced the concept of partial and full compatibility. Partial compatibility means that there incompatibilities but that depends on whats written, for example an enum [A, B, C] is partially compatible with the enum [A, B] but depends on what the writer has written.

Users wishing to be absolutely sure, can treat Compatibility::Partial as an error, others can use it to slowly upgrade from an old schema.

Depends on #339, should be rebased after that's merged

[martin-g]

I'm afraid I cannot approve this PR :-/
I tried twice to review it but it is too big and there are API breaks which I think are not really necessary.

Partial compatibility means that there incompatibilities but that depends on whats written

How can one be sure what has been written with a given schema ? Anything that the schema accepts could be in the file. I cannot make assumptions that parts of the schema were never used.

If you strongly believe that it is better and it won't cause problems to the other users then feel free to merge it!

[Kriskras99]

I'll remove the partial compatibility and do some more testing to compare the new version with the old version (I'll see if I can get a fuzzer to run).

[Kriskras99]

I unfortunately couldn't get a fuzzer to work, the recursive branchy code makes it hard for the fuzzer to select new paths.

I took a look at Compatibility again, and I think it should stay. Here's a comparison of behaviour:

Writer	Reader	Old	New
Union<Null, Int>	Null	Ok	Partial
Union<Null, Int>	Int	Ok	Partial
Null	Union<Null, Int>	Ok	Partial
Int	Union<Null, Int>	Ok	Partial
Union<Null, String>	Union<Null, Int>	Err	Partial
Int	TimeMicros	Err	Full
Enum<A, B, C>	Enum<A, B, C, D>	Ok	Full
Enum<A, B, C>	Enum<A, B>	Err	Partial

So the new behaviour allows slightly more, but is also more honest about the compatibility.
A user who wants absolutely no schema evolution errors, can check for Ok(Compatibility::Full), while a user who can allow that can just check is_ok.

What do you think based on this table?

[martin-g]

The CI checks didn't run for this PR for some reason.
There are Clippy errors:

error[E0658]: `let` expressions in this position are unstable
   --> avro/src/schema_compatibility.rs:116:12
    |
116 |         if let Some(w_name) = writers_schema.name()
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information

error[E0658]: `let` expressions in this position are unstable
   --> avro/src/schema_compatibility.rs:117:16
    |
117 |             && let Some(r_name) = readers_schema.name()
    |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information

[Kriskras99]

Ah, that was made stable in 1.88. So shall we bump the MSRV or shall I rewrite it with a match statement?

Also the CI not running was me messing with target branch

[martin-g]

Let's bump!
This will allow to update Darling too.

[Kriskras99]

Version bumped and new lints fixed (some lints are gated behind the rust-version setting in Cargo.toml). If you agree with the table in #342 (comment) this can be merged.

[Kriskras99]

Rebased on main, and test added for resolving Decimals with different inner types.