[robert-brunel]

• Replace the naive O(N²) implementation of renameRecordTypes(), which renames the types one by one via renameRecordType(), with an efficient batched version that applies all renames in one go.
• Cleanly split the per-rename validation from the actual mutation throughout, so that the whole batch gets validated before anything is mutated.
• Add a RecordTypeRenames data structure that indexes renames by fully qualified name to avoid having to scan all renames per item. This brings what would otherwise still be an O(N²) algorithm down to O(N).
• Leave renameRecordType() itself untouched for the time being. It will be simplified in a subsequent change by “rebasing” it on the utility methods introduced here.

The batched implementation performs the costly compilation of the FileDescriptor exactly once (via Descriptors.FileDescriptor.buildFrom(), from the original proto) and applies the name mapping in a single walk of the builder. The trivial implementation, by contrast, performs a recompilation of the entire records FileDescriptor plus a full records.toBuilder() deep-copy in each iteration of the loop over the record types. In the common use case where all top-level record types are to be renamed, that means O(N) descriptor compilations for N record types.

Applying multiple renames in the batched manner is equivalent to applying them one-by-one, provided that the name mapping defined by the given renamer is collision-free. The batched implementation validates the mapping upfront. This allows it to provide a stronger exception safety guarantee. If the mapping is invalid, an exception will be thrown before any of the renames is performed. The one-by-one implementation, by contrast, may raise an exception halfway through; and that may depend on the order in which the renames are applied.

Testing

• Cross-check renameRecordType() and renameRecordTypes() against each other throughout the existing test suite.
• Add dedicated tests for every MetaDataException reachable from renameRecordTypes(), plus a couple of previously unexercised edge cases.
• Fix an unrelated, pre-existing bug in the Joined.json test fixture (a join referenced a nonexistent constituent), uncovered along the way.
• Add a performance test that renames a large number of record types. In a local ad-hoc experiment, measured after warmup as the median of 11 runs, the batched implementation was about 15× faster than an equivalent one-by-one sequence of renameRecordType() calls with 50 record types (0.12 ms versus 1.7 ms), and about 76× faster with 250 record types (0.46 ms versus 35.0 ms), which is consistent with the O(N) vs. O(N²) difference.

[alecgrieser]

Overall, this looks good. I mainly focused on the documentation (and what it means from an API perspective) and the main implementation, so I didn't really look at the tests. I have a few concerns about drift between renameRecordType and renameRecordTypes, and I'd rather we aligned the methods, in general, rather than marking the difference. I guess I could see doing that as a follow-up, though.

[ScottDugas]

I few more things that still seem a bit messy about the api of renameRecordTypes. I am honestly not sure whether it makes sense to continue improving this API as part of this PR, or add them separately to the stack.

[alecgrieser]

LGTM