Always treat groups as message fields

[jchadwick-buf]

The relative simplicity and obviousness of this fix greatly obscures how difficult it was to determine :)

Protobuf editions adds a couple "new" features to protobuf that cleverly re-use old protobuf wire and language features.

In case of expanded repeated field representation, there appears to be no difference: for repeated fields, protobuf already supported both wire encodings, and protoreflect already had to treat them the same. Thus, repeated fields with both encodings work fine with protovalidate-go.

In case of delimited message representation, this uses the old proto2 group encoding. This almost works, because protoreflect treats groups and submessage fields very similarly, and some of the protovalidate-go code also already handles groups as expected.

Unfortunately though, there were a few places where groups and messages were not being treated identically. The failure case is rather obscure: almost everything works, but some special cases are not taken correctly with the group encoding. This in and of itself is not automatically a problem but it can lead to weird issues, most notably the subtype not being discovered and registered correctly in the dynamic case.

Although I did not individually test each line change to make sure that it fixes a specific bug, most of these are definitely needed and fix behavioral issues, except I am not 100% sure about the pgv migrator (Probably unnecessary but if proto2 groups work in pgv it seems fine for good measure.) I will make a separate PR to protovalidate that includes plenty of new test cases that ensure editions works; most of these pass on main save for some of the delimited submessage ones.

cel-go seems to behave correctly already. I initially suspected a problem with how it handled delimited submessages, but it was a red herring.

[jchadwick-buf]

Test cases are now added in bufbuild/protovalidate#225

[timostamm]

If this fixes behavior with edition 2023 message fields with features.message_encoding = DELIMITED, this also fixes the same issue with proto2 groups.

Proto2 groups are really only syntactic sugar. When compiled to descriptors, the keyword synthesizes a message for the group, and adds a field with TYPE_GROUP that references the message. When serialized, the field is delimited by start end end tags instead of a length-delimited tag.

The edition message_encoding feature is intended to reproduce the wire representation, but in descriptors, it's represented as a regular message field with TYPE_MESSAGE, and the feature DELIMITED in an option.

protoreflect however aims to have a single representation, and translates the DELIMITED option back to field kind group. So as long as we treat TYPE_GROUP the same as TYPE_MESSAGE, we should be good with both proto2 groups and edition DELIMITED (assuming we don't do any serialization).

[jchadwick-buf]

Yeah, I had the same feeling, this should definitely fix proto2 groups. I assume we don't have any tests for proto2 groups currently, but we could always add some if desired.

Either way, I definitely have an appreciation for how clever the 2023 edition features are. It seems like if you were using official protobuf reflection libraries and supporting all of the proto2 and proto3 features it "just works", so fixing editions support is really just fixing support for those features.

[jchadwick-buf]

I think we're good to go now. @rodaine want to take another quick look before I hit the button?