Relax validation of ID attribute

[paultyng]

Fixes #607

Currently in the InternalValidate validation, we prohibit any explicit overriding of the id attribute for resources in favor of writing an explicit version. But this does not allow modifying the Optional bit, or setting a custom Description which is useful for docs generation and the language server. This allows implementers to override the id if they so choose as long as it still adheres to the rules specified for the built-in usage.

[bflad]

Conceptually looks good to me. 😄

[radeksimko]

I'd be curious to see how this affects the schemas of top N providers - whether any of them would fail this validation and why.

I remember tweaking the internal validation in the past myself which brought many surprises and lead to some reverting later. 😅

---

I may have missed some recent updates around ID handling, but on what occasion would a resource want to make id optional? I'm aware that id has lost its special status in core, but aren't there still SDK parts which treat it as special? e.g. we haven't really gotten rid of ResourceData.Id() or ResourceData.SetId() - this was one of the reasons for the strict validation AFAICT. I guess it's fine if calling SetId(val) & Set("id", val) and Id() & Get("id") have the same implications? They don't seem to though.

The description use case makes sense to me though.

[paultyng]

Resources IDs are currently optional, this is letting you turn it off.

[radeksimko]

Ah, that's fair then 👍

[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.