Set a UUID when building a Schema object.

[scwhittle]

Schemas are immutable so this meets the guarantee that a consistent UUID is used for matching schemas. Cleanup some cases setting a random UUID after creating Schema, fix case where same UUID was assigned to different Schema after sorting, and use Immutable data structures to enforce immutability.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[Abacn]

Thanks, this PR contains several indepenent fixes, I'm good with most of them, but not sure about the oneOfType one, suggested to involve other reviewer who might now

[Abacn]

this looks like a breaking change. However I am not sure the implication, good to involve others reviewer, possibly @robertwb ?

[scwhittle]

The previous behavior seems incorrect as proto serialization is not necessarily deterministic and the serialized proto equality doesn't match schema equality logic.

But I think that you are correct that this would break schema update compatability because LogicalType base class appears to be serializable.

@robertwb Any ideas on how to best proceed? We could

1. keep OneOf as-is and just document that it's equality isn't guaranteed to be correct due to proto serialization and clear the uuid before serializing the proto.
2. add a new type with correct semantics and deprecate this one
3. try to integrate w/ update compatibility version but that seems difficult given schemas are created all over. We coudl have some static method we call that modifies static state instead of plumbing the option everywhere. getArgument base is to return an Object so we can have single class support both types based upon the configuration.

[robertwb]

Good question.

First, let's separate this change out into its own PR, so we can get the rest (which looks good) in.

I'm worried about what existing pipelines might break if we change this. Does a (null?) Row eventually get serialized with its schema as proto bytes anyway? We could look into explicitly using deterministic proto serialization here as an improvement at least.

[scwhittle]

Some change of OneOf is needed because it's schema now has a uuid set and thus doesn't compare equal.

However I changed to keep using serialized proto but to recursively remove the UUID from the schema proto before serializing.

PTAL

[scwhittle]

Errors appear unrelated flakiness, retriggering but ready for a look

[scwhittle]

Run Java PreCommit

[scwhittle]

Run Java_IOs_Direct PreCommit

[Abacn]

Test failure testMultipleClientsFailingIsHandledGracefullyByServer know issue: #30056, unrelated.