Implement deepCopy as copying, instead of merge

[osa1]

Currently when we copy a message we create an empty message, and then merge the
copied message to the empty message.

This is not optimal as merging is a more complicated operation then copying.

This implement deepCopy as simple deep copy and halves deepCopy benchmark
results.

GeneratedMessage.deepCopy also gets a optional freeze argument for
optionally generating frozen messages. Previously we would have to copy and
then make another pass to mark the message as frozen.

Changes:

• deepCopy method added to PbList, PbMap, _ExtensionFieldSet,
  UnknownFieldSet, _FieldSet

• GeneratedMessage.deepCopy now calls _FieldSet.deepCopy, doesn't use
  merging

(I also removed generating clone() overrides, but I will revert it for now
and maybe do it in a separate PR)

Benchmarks:

• Before: protobuf_deep_copy(RunTimeRaw): 635.2863492063492 us.
• After: protobuf_deep_copy(RunTimeRaw): 307.04386503067485 us.
• Diff: -328.23 us, -51.66%

---

cl/470187112

[sigurdm]

Please leave a LDAP or an issue number in todos.

Suggested change

	null, // TODO: event plugin
	null, // TODO(omersa): event plugin

[sigurdm]

Same here

[sigurdm]

You could possibly use List.generate to fill in the right values from the start, thereby avoiding the re-allocation.

[osa1]

This causes a lot of breakage internally. I think one of the reasons is probably that I'm assuming PbList for repeated fields and PbMap for map fields, but map and list allocation is done via GeneratedMessage.createRepeatedField (returns List<T>) and GeneratedMessage.createMapField (returns Map<K, V>). I should check the field type (instead of field value type), and use Map and List API similar to how we merge map and list fields.

Since we can't have nested lists and maps, cloning of nested maps and lists will have to go through GeneratedMessage.deepCopy, which will again look at field types and use List/Map API to clone maps and lists. So we won't need deepCopy in PbMap and PbList types.

Interestingly, we assume PbList and PbMap in _FieldSet._markReadOnly:

void _markReadOnly() {
  if (_isReadOnly) return;
  _frozenState = true;
  for (var field in _meta.sortedByTag) {
    if (field.isRepeated) {
      PbList? list = _values[field.index!];
      if (list == null) continue;
      list.freeze();
    } else if (field.isMapField) {
      PbMap? map = _values[field.index!];
      if (map == null) continue;
      map.freeze();
    } else if (field.isGroupOrMessage) {
      final entry = _values[field.index!];
      if (entry != null) {
        (entry as GeneratedMessage).freeze();
      }
    }
  }

  _extensions?._markReadOnly();
  _unknownFields?._markReadOnly();
}

If I'm right that the breakage here caused by users overriding list and map field types, then I'm not sure how _markReadOnly works. Maybe users that override map and list types never freeze their messages?

We should just rewrite this library..

[osa1]

I managed to fix at least some of the downstream breakage by removing the assumptions in the implementation about repeated fields being PbList and map fields being PbMap.

The fact that we csan't assume this means freezing messages is buggy, for the reasons described in my previous comment above.

Performance is still much better than merge-based implementation. I will update the PR description, and refactor the code a little bit (document, revert some of the changes).

[osa1]

I managed to fix at least some of the downstream breakage by removing the assumptions in the implementation about repeated fields being PbList and map fields being PbMap.

This version fixed some of the previous failures, but introduced new ones.