feat: enforce near-abi version match

[itegulov]

Fixes #61

Just a dumb MAJOR.MINOR check for now, we can tweak it later if needed

[itegulov]

Will add a test for this once we release near-sdk 4.1.0-pre.4 with near-abi 0.2.0

[miraclx]

Hm, should we be testing with the crate version? or the schema_version?

[itegulov]

The reason why this check is needed in the first place is because ChunkedAbiEntry returned from the dylib artifact has to conform to the ChunkedAbiEntry used by cargo-near, which depends on how Rust ABI views them. For example I highly doubt that Rust would allow you to interpret:

pub struct AbiMetadata {
    pub name: Option<String>,
    pub other: HashMap<String, String>,
}

and

pub struct AbiMetadata {
    pub name: Option<String>,
    pub version: Option<String>,
    pub other: HashMap<String, String>,
}

as the same object even if they both can belong to the same schema_version (extending metadata object does not bump the schema version obviously).

If we were to switch back to JSON-based ABI chunk generation, then we would be able only to check the schema_version.

[miraclx]

Yeah I understand that, suggesting we could consider returning serde_json::Value from the chunks, instead of the strict type. Then we can leave it up to the deserialization implementation to do the validation. Or what do you think?

But as-is works too.

[itegulov]

Hmm, that could work. In general, do you know what invariants you can depend on when working with low-level Rust ABI? For example, is it reasonable to assume that serde_json::Value is going to have the same ABI for all major.minor releases? Also, would I have to re-compile cargo-near whenever I install a new version of rustc?

[miraclx]

Not sure, honestly, best path to avoid inconsistencies later down the line would probably be to return JSON strings. And manually handle deserialization wherein we can validate the schema_version.

[itegulov]

Yeah, that's what I am thinking too right now. Any ideas on how to get schema_version from a crate though? Can we add like a custom cargo metadata key or something?

[miraclx]

So, ChunkedAbiEntry already includes schema_version.

Which means we can only do the compatibility check after the Generating ABI step.

EDIT: ... or rather, during..

[miraclx]

I especially like that ChunkedAbiEntry already does this compatibility check on deserialization.

https://github.com/near/near-abi-rs/blob/368245073aa5bf919ee30f9e6f2246f68eee1b40/near-abi/src/private.rs#L11-L12

So we get this for free.

[itegulov]

True, I will prepare an alternative PR then

[itegulov]

Closed in favor of #74