Update Commit.id to not validate as a UUID

[saquibmian]

Commit.id <=> RepositoryCommit.name, which is a dashless UUID.

This also implies that ResourceRef.value.id is not a UUID.

TODO:

• This is now inconsistent across the API surface. Should we drop the UUID validation on all IDs? Ideally our IDs are opaque to users and we are not expressing their shape in the API. Alternatively, we add Commit.name back and Commit.id <=> RepositoryCommit.id and Commit.name <=> RepositoryCommit.name.

[nicksnyder]

The inconsistency between some IDs are UUIDs and other aren’t is a bit unfortunate.

I think we should leverage Protovalidate for basic sanity checking of input as much as possible, so I don't think we should remove (buf.validate.field).string.uuid = true from id fields where it is valid.

For fields that can't use the build-in (buf.validate.field).string.uuid = true rule, we shouldn't just remove it, we should replace it with actual validation. It sounds like they are in fact UUIDs without the dashes, so let's validate that.

[saquibmian]

It sounds like they are in fact UUIDs without the dashes, so let's validate that.

Are we sure we want to go down that path? We are exposing the shape of our IDs, and we cannot change this later.

In the meantime, I'll update the validation rules to validate a dashless UUID.

[nicksnyder]

I assume we could write a CEL expression that essentially validates this field is either a UUID or whatever the validation is for a commit id (sounds like it is a UUID without dashes).

[nicksnyder]

Are we sure we want to go down that path? We are exposing the shape of our IDs, and we cannot change this later.

This is an interesting philosophical question. My two arguments in favor are:

1. In practice, it is nice to be able to rely on protovalidate to validate basic things like this.
2. In theory, even if we remove these validations from the schema, Hyrum's law will apply (people will see that in practice we are using UUIDs everywhere).

Therefore might as well put it in the schema and accept that if we are compelled to change this later it would be a breaking change in that sense.

[nicksnyder]

Discussed in person. Consistently using UUIDs is important enough that we should first consider what work we would need to do to make the implementation consistent so commits use UUIDs.

[saquibmian]

Closing this PR, the BSR will take care to translate name to id and back as needed. We discussed this as a team and would like to prioritize the best API possible. Decision doc here.