Add protovalidate lint rules

[oliversun9]

This PR adds PROTOVALIDATE rule to buf lint.
It checks

• all CEL expressions compile
• rules permit some value. For example, gt: 5 and lt: 1 reject all values
• rules match the type of the field. Wrapper types can also match rules for its value type
• rules are not obviously redundant. For example, if const is specified, other rules are obviously redundant. However, if string.min_len is 5 and string.min_bytes is 4, the latter is redundant but this is not obvious. (I initially had a quite many redundancy checks. I removed them after discussing with @rodaine)

If the .proto author wrote options in non-aggregate form, buf lint can pinpoint. If the options are written in the aggregate form, then everything between the braces gets highlighted, since that's how source code locations are generated.

Non-aggregate

 uint32 a = 5 [
   (buf.validate.field).uint32.lt = 10,
   // only the next line is highlighted
   (buf.validate.field).uint32.const = 1,
   (buf.validate.field).uint32.gt = 8
 ];

Aggregate

uint32 a = 5 [
  // the next 5 lines are highlighted
  (buf.validate.field).uint32 = {
    lt: 10,
    const: 1,
    gt: 8
  }
];

[bufdev]

This is approved given the following:

• Add a test that will fail given the custom parsing of cel-go's error messages.
• We get the PR for the rest of protovalidate rules up in parallel. I'd like to merge them together, and to evaluate the final name for the respective lint rules (and perhaps combine them into one).

[jhump]

Is this true? What bootstrapping errors do we expect? If we're using the buf CLI to work on buf, we're working with a binary where the remote packages are already resolved and compiled, so I don't see how this is a problem here.

I was under the impression that it's the core repo that must not depend on generated SDKs. Note that this directive here will do nothing to prevent a cyclic dependency in core since replace directives in dependencies are ignored by the go tool.

[oliversun9]

we're working with a binary where the remote packages are already resolved and compiled

The buf CLI's binary itself will be fine, since like you said, it's just a binary.

Note that this directive here will do nothing to prevent a cyclic dependency in core since replace directives in dependencies are ignored by the go tool.

Yes I think this is the concern and we will also need to add a replace directive there, before or around the time when this PR is merged.

[jhump]

Yes I think this is the concern

So we can remove the replace directive here?

[oliversun9]

Great question, and with the reasoning above I think it's probably fine? @bufdev what do you think?