Remove or document field set implementations for extensions and unknown fields

[osa1]

Currently we have 3 field set implementations:

• For known fields: https://github.com/google/protobuf.dart/blob/faa266368030556340650b7eb79bc0a98d6e4dc9/protobuf/lib/src/protobuf/field_set.dart

  A field is known if we have the field in the .proto file for the message.

• For unknown fields: https://github.com/google/protobuf.dart/blob/faa266368030556340650b7eb79bc0a98d6e4dc9/protobuf/lib/src/protobuf/unknown_field_set.dart

  A field that we see in a serialized message is unknown if we don't have it defined in the .proto file for the message.

• For extension fields: https://github.com/google/protobuf.dart/blob/faa266368030556340650b7eb79bc0a98d6e4dc9/protobuf/lib/src/protobuf/extension_field_set.dart

I don't understand why we need 3 different implementations and it's not documented. Conceptually we just need to map integers (field tags) to proto values. As far as I understand, the only difference between a known field and an unknown field is that for unknown fields FieldInfo won't be available. We don't need this much code for this.

We will probably need a new value class (like PbMap, PbList) for unknown length-delimited values (strings, bytes, messages, repeated fields). The representation will just be Uint8List.

I'm not sure if we need to support groups, but we will need another value class for unknown groups, with Uint8List to store the group contents.

When we need to check whether the field for a tag is known, unknown, or extension, we could have Set<int> unknownFields and Set<int> extensionFields in _FieldInfo.

One question is how to merge two unknown groups or length-delimiteds. Merging values is not specified in proto spec. We have two options:

• Collect values of merged groups and length-delimited stuff. This means PbUnknownLengthDelimited (or whatever we want to call it) will store List<Uint8List> instead of just Uint8List, and add to the list as we merge values. Same for groups.

  This is currently what we do in UnknownFieldSet.

• Override the current value. This is simpler.

If I'm missing something and we really need 2 extra classes and a few hundred extra lines and tests then we should document why this is needed.

[sigurdm]

I don't know the history for why these are represented separately - but I agree - it is better to gather these into one FieldSet class - that avoids inconsistencies between them. (They could even potentially be folded into GeneratedMessage - but I think there's a good reason not to do that: All the calls on FieldSet can stay monomorphic - if they are calls on subclasses of GeneratedMessage they might go polymorphic...)

[osa1]

UnknownFieldSet is not a private type and we have a few users. I checked the users, we have two use cases:

• To generate protobuf binary messages without a proto description. For example:

  UnknownFieldSet()..addField(
      1,
      UnknownFieldSetField()..addVarInt(123)
  ).writeToBuffer()

  If we had a public field type class/enum, we could use CodedBufferWriter for this use case: (not tested)

  CodedBufferWriter()..writeField(1, FieldType.int32, 123).toBuffer()

  (See Introduce a class for field types #605 for adding a public field type class)

• To skip fields in custom protobuf deserializers:

  UnknownFieldSet().mergeFieldFromBuffer(tag, input)

  (where input is CodedBufferReader)
  For this use case we could provide a CodedBufferReader to skip fields. I don't think we have anything else other than UnknownFieldSet that covers this use case.