feat: full spec version implementation

[tabaktoni]

Motivation and Resolution

Expand subversion specification validation on provider instantiation with create().

• SupportedRpcVersion is now the full spec version 0.8.1
• [provider, channel].readSpecVersion() read recorded spec version from channel
• [provider, channel].getSpecVersion()fetch from API full spec version
• [provider, channel].setupSpecVersion() has functionality of old getSpecVersion(), return spec version if recorded else fetch, test for supported versions and store if fine, else throw error
• RpcChannel.channelSpecVersion constant specifying for which specversion the channel is designed

Usage related changes

Moved version and resolution util methods from utils/provider to utils/resolve

Development related changes

Spec version is now in full form major.minor.patch (actual starknet spec is major.major.major)

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Linked the issues which this PR resolves
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[penovicp]

A couple of rewording suggestions, otherwise lgtm

[PhilippeR26]

So, these codes that are valid for Starknet.js v7.1.0, will be no more valid:
const myProvider = new RpcProvider({ nodeUrl: "https://free-rpc.nethermind.io/sepolia-juno/v0_7", specVersion: "0.7" });
console.log( "rpc =", await myProvider.getSpecVersion()
What's the motivation of this breaking change? Has someone requested it?
Isn't a patch number increase allowed only for non-breaking changes?
If the patch number become discriminant, is Starknet.js v7 compatible with rpc 0.7.0 & 0.7.1? with 0.8.0 & 0.8.1?
Or only with 0.7.1 & 0.8.1? Will other patch versions be rejected when aRpcProvider will be instantiated?
We asked to Lava network to discriminate major.minor nodes versions. What will happen with this PR?

[tabaktoni]

As described isVersion has been refactored to work with a wildcard, so during dev expectation is:
isVersion('0.7', spec) it's the same as isVersion('0.7.*', spec) or any 0.7.x version is true.
The only breaking change is the actual spec 'enums', but if they are used as consts it should not break as it will be updated in client code to the new value.

What's the motivation of this breaking change? Has someone requested it?

Yes, SW to detect patch Spec incompatibility. As spec versioning is described as major.major.major whitch means all subversions are breaking, some more, some less. So the only logical solution is to have full version dininition in the code.

Isn't a patch number increase allowed only for non-breaking changes?

Yes, but for starknetjs we are in pre-release and haven't done v7 main release yet for exactly that reason. Once we do, we can't introduce any more breaking changes before v8. For spec, it is as described above, but it is expected even do I would argue spec should only have major and minor.

If the patch number becomes discriminant, is Starknet.js v7 compatible with rpc 0.7.0 & 0.7.1? with 0.8.0 & 0.8.1?

There are only warnings for patch mismatches and errors on major mismatches.

[github-actions]

🎉 This PR is included in version 7.2.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀