don't validate Min/Max block vals in CoerceValue

[jbardin]

A provider may not have the data to fill in required block values in all
cases during the resource Read operation. This is more common in import,
because there is no initial configuration or state, and it's possible
some values are only provided in the configuration.

The original intent of MinItems and MaxItems in the schema was to
enforce configuration constraints, not to enforce what the resource
could save in the state. Since the configuration is already statically
validated, and the Schema is validated against the configuration in a
separate step, we can drop these extra validation constraints in
CoerceValue and relax it to only ensure the types conform to what is
expected.

Closes #22387
Issue 22387 is not an exhaustive list, but the representative that the issues are mostly encountered by the providers.

Also related to #22414, though that will require a change to the decoder spec as well. Unfortunately that does remove a layer of validation we would like to keep. We can fix that by creating a new function like AssertObjectCompatible that validates the final wholly-known value against the schema.

[pselle]

coerceValue does a lot! From its stated documentation, I can see removing the min/max validation in coerce value, if that's not this function's job.

[paddycarver]

@jbardin this is called from core, not the SDK, right? So providers don't need to re-vendor for this to be fixed?

[jbardin]

No, this is only really called from the SDK. Though there will be a follow up PR that should be included with this, so there's no need to re-vendor it yet.

[paddycarver]

👍 Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.