Detect newer specs used with older providers

[jyecusch]

Feature Request

Suggestion

When using a newer version of Nitric (with a new feature in the project spec), older providers will typically still work, but the new features will be ignored.

Ideally, this would present a warning or optional error instead, so it's clear that something won't be deployed as expected.

Value

Avoids issues where a project appears to use a new feature correctly and deploy, but it's missing in the deployed output.

Alternatives

Select compatible version or check the deployed resources to ensure everything was deployed.

Other info

[tjholm]

Starting at the resource type level for this might work OK for this, add a check for all providers to find all resource types that they cannot identify (as they don't have the enum definition available in their compiled sources).

Because we use available configuration data at the moment we don't handle a default unknown case (maybe we can use the case statement to do this)

Another option could be a simple resource type check:

_, ok := resourcespb.ResourceType_name[int32(res.Id.Type)]
if !ok {
	return fmt.Errorf("unknown resource type %s", res.Id.Type)
}

Basically if a resource type is out of range of the providers current knowledge of the contracts we can fail or warn.

So if the CLI sends an expected resource type that the provider cannot identify then there is a clear capability gap between the two (or a breaking API change which would be a much worse scenario).

We could also implement new APIs for providers to do this as well, where they simply check their contract capability against a spec sent by the CLI and provide output such as warnings/errors for the CLI to pass on to the user.

Need to think about other kinds of incompatiblities such as new runtime API methods for resources and how we could handle these as implicitely as possible as well 🤔. We could possibly sanitize and then hash the contracts to try and identify capability gaps, or maintain a constant enum in the contracts that represents the capability boundaries and warn/error where unknown capabilities arise. Or do something a bit more naive like tracking semver and warning on that (that may be a bit too simple though as not all version discrepancies at the minor version level represent capability gaps between CLI and providers)