Implement deepCopy as copying, instead of merge

[osa1]

Currently deepCopy and clone create an empty message, and then merge the
cloned message into the empty message.

This is slow as merge needs to validate each element added to the message.

In this PR we instead directly copy the field set, and deeply copy map, list,
and message fields.

deepCopy benchmark results:

	Before	After	Diff
AOT	238 us	151 us	-36%
dart2js -O4	242 us	140 us	-42%
dart2wasm -O2	230 us	123 us	-46%
JIT	189 us	104 us	-44%

This CL is tested internally in cl/794080754.

Fixes #60.

[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.

[osa1]

We should revive this as it improves cloning performance quite a bit (50% according to my original report in PR description).

As far as I understand from the discussion above the main issue was repeated and map fields were overridden by message classes, but we've since removed those members (96d9522) so this should probably be good now.

It might make sense to just implement this again from scratch instead of fixing this PR.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:protobuf	5.0.0	(error) pubspec version (5.0.0) and changelog (5.0.0-wip) don't agree
package:protoc_plugin	23.0.0	ready to publish	protoc_plugin-v23.0.0

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[osa1]

@devoncarew @sigurdm I rewrote this PR from scratch and force-pushed (it was bitrot). I resolved all previous discussions because the code is different.

Note: the plugin changes are not synced to the CL yet and not tested internally yet. I'll sync it later today and start a global presubmit with the plugin changes. The library changes are tested globally. Update: it's being tested now.

[sigurdm]

LGTM

[devoncarew]

We should update the pubspec version to agree w/ the changelog (=> 5.0.0-wip). If we do plan to publish after landing this (no particular opinion), we can change both versions to 5.0.0).

[osa1]

Didn't we discuss this already? #1037 (comment)

5.0.0-wip breaks the build because it's not considered 5.0.0, and plugin now needs 5.0.0.

We can update the changelog before or even after releasing 5.0.0.

[devoncarew]

Ah, yes, I'd forgotten.