Events notification system for Nessie - VersionStore changes

[adutra]

This PR is part of a series of PRs related to the events notification system for Nessie.

See design doc: https://github.com/projectnessie/nessie/blob/main/design/events.md.

This PR focuses on changes required to the existing VersionStore API and implementations.

Summary of changes:

• New EventsVersionStore implementation following the delegate pattern already used for metrics and tracing. Not used for now.
• Most methods in VersionStore now return more detailed results:
  • commit() returns CommitResult
  • assign() returns ReferenceAssignedResult
  • create() returns ReferenceCreatedResult
  • delete() returns ReferenceDeletedResult
• The existing MergeResult now has more methods:
  • BranchName getSourceBranch();
  • List<COMMIT> getAddedCommits(); this is the most tricky addition
• The new LazyPut interface: contrary to Put, it does not deserialize the content value until it's necessary to do so. (The goal is to avoid deserializing contents on Nessie's write path, if the REST API doesn't need it.)

All these additions are meant to be consumed by the events system, not by the REST API which does not change at all, as required by the design doc.

[snazy]

Not a full review (and not done yet), but went though a bunch of files.

Adding all the *Result objects to the VersionStore functions is fine.
Not so much a fan of the new "top-leve" LazyPut (commented).

I suspect, with some of the suggestions applied, the size of the PR will reduce a bit.

[snazy]

Thanks!
I'll take a closer look probably next week.
Just a few rather minor comments for now, nothing serious.

[snazy]

Veeeery close :)

Just a few more minor-ish comments and then we can ship it.

[snazy]

Just noting (nothing to change here) - only for posterity why this is not in the new model:
Initially I ported this behavior to the new storage model as well, but (manual, bad "heavy load") tests proved that this can go sideways - up to the point that two concurrent writers produce the exact same commit, one wins and bumps HEAD, the other one "loses" and deletes the commit -> HEAD points to a non-existing commit. It's a rather artificial and will probably never happen in real-live, but still, there's a chance.

[snazy]

Boom! Ship it! :)