[Feature Request] Internal and external validation

[ash2k]

Feature description:

Allow to have "external" and "internal" (example names) validation rules on fields/messages/etc. External proto message consumers would use the "external" rules and internal consumers - both "external" and "internal".

Problem it solves or use case:

There is clearly demand for using custom functions in CEL (e.g. bufbuild/protovalidate-go#73, bufbuild/protovalidate-go#118, bufbuild/protovalidate-go#119). Reasons:

• Greater flexibility. Not everything can be written in CEL.
• Greater speed. Some non-CEL implementation may use assembly for faster validation.
• Desire to avoid re-implementing pre-existing validating code in CEL. I'd use an off-the-shelf function from a library for [Feature Request] Validation for bytes #264 if I could inject it.
• Work around bugs ([Feature Request] Validation for bytes #264 - I'm stuck!).

Currently protovalidate is not meeting the demand for this functionality.

Proposed implementation or solution:

From the explanation here, it seems that the concern is that there will be proto messages that cannot be used outside of a project because they require some custom validation function. I think this is a valid concern.

What if we have a separate CEL-based validation option (repeated?) that allowed the user to use custom functions in it? The user would configure the validator with custom functions and a list of messages for which such custom ("internal") validation is enabled.

This would avoid the problem as all the existing and custom rules would not use any custom functions - they are good, safe for external consumption. They cannot have any custom functions now or later and will not break importing code (as today). At the same time for in-application validation users can utilize the new mechanism for their messages specifically.

Contribution:

I haven't looked at the code, but it should be quite straightforward. I'm willing to contribute this.

Examples or references:

Additional context:

Please think about the current situation. If I cannot use protovalidate to run validation on my message, I need to make this part of the app logic. This validation might be on multiple messages, potentially nested in other messages, all over codebase. So, naturally, I would want to use a "choking point", like gRPC interceptors, to ensure all the messages are validated. I'll have to re-implement a lot of what protovalidate does to walk those messages and validate the ones I need. It feels very wasteful - a lot of people will have to rebuild this.

Another approach I considered is to have a separate validator, compose multiple validators into an aggregate validator. Each does it's validation. The problem is the overhead of walking each message using reflection more than once.

Yet another approach is to allow user to inject functions with predefined signature that protovalidate would match the messages against. E.g. funct (m *MyProtoMessage) error (this is for Go). It would be called for messages, assignable to the type of the argument of the function. This is like an interceptor for protovalidate. The benefit of this approach is that there is nothing in the proto file, there is no CEL evaluation either. Just direct code that validates the message.

Can we come up with a mechanism in protovalidate that ticks all the desired boxes for both maintainers and consumers?