Add structured field and rule paths, field and rule values to ValidationErrors

[jchadwick-buf]

This implements the structured field and rule paths, passing the conformance test changes in bufbuild/protovalidate#265.

In addition, it also adds the ability to get the field and rule values. These are not present in the protobuf form of the violation.

The API is still heavily centered around the protobuf form of violations, but the ValidationError type is no longer an alias to the protobuf buf.validate.Violations message. The intention is that users needing access to the error information will still use the proto violations message, only using the "native" interface methods to access in-memory data that is not feasible to transport over the wire. (e.g. protoreflect.Value pointers.)

DO NOT MERGE: Need to revert e948b95 and update the protovalidate dependency when bufbuild/protovalidate#265 is merged.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / validate-protos (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Nov 7, 2024, 12:08 AM

[jchadwick-buf]

Well, it took a while, but I think this is the most bang-for-our-buck possible. I think it's not the best possible code by any single measure, but I tried to balance concerns of performance, simplicity and API surface. A lot of thought was put into exactly how paths are constructed: as before, we avoid constructing paths unless a validation error is actually encountered. A careful adjustment is made to the builder code to add just enough information to be able to produce the rule paths accurately in as many edge cases as I could find, without requiring new special cases to be distributed in more places. To minimize the resulting API surface of changing the error type, the protobuf form of a Violation is still the primary way to consume a Violation, and we only need to add a utility function and an additional type to the protovalidate package.

It would be difficult to convey the number of different considerations that wound up needing to be made, but hopefully the resulting code does not make this difficulty apparent. :)