HDDS-15374. Switch Recon to the new versioning framework

[errose28]

DRAFT Requires #10366, #10367, #10368, #10370, #10376, and #10437 to be merged. This PR contains those changes as well.

What changes were proposed in this pull request?

Create a new ReconVersionManager and corresponding upgrade action provider to manage Recon's versions and finalization. By switching Recon to the same framework as other components, we are able to remove a large amount of custom upgrade code that was previously unique to Recon.

Recon currently handles finalization differently than other components and this is unchanged by this PR:

• Recon finalizes automatically on startup. The move of the apparent version to match its software version is only to run reformatting actions.
• Recon never used the component version framework previously, so we can switch its ReconLayoutFeature class to ReconVersion implements ComponentVersion with no migration concerns
• Recon also has an HDDSVersion the same as SCM and Datanode inside its NodeManager implementation, which is stored in a VERSION file.

Existing Issues Fixed

• Before this PR, the persisted HDDS version in Recon was never updated, so it would remain at the software version Recon was first initialized in. This just happened to work because Recon's NodeManager was only depending on apparent version (MLV before the switch) for debug logging.

  • This may not be true going forward, so this PR finalizes the HDDS version with the Recon version on startup.
  • In HDDS-15482 we should finalize this HDDS Version when Recon sees a finalized Datanode to keep Recon's HDDS version in sync with SCM and Datanode.
    • HDDS-15482 will also add logging based on the software/apparent version matrix between SCM and Recon. The existing logging has been removed for now.

• The standard in the upgrade framework is that INITIAL_VERSION serializes to 0, and represents the state before any upgrade framework was introduced, meaning no version is found on disk. -1 is the in-memory serialized value representing an unknown/future version in the ComponentVersion framework.

  • Recon was using -1 as the in-memory placeholder to represent no version on disk, and then INITIAL_VERSION = 0 as the first version to introduce the upgrade framework. The creates a conflict with the standard versioning framework
  • Recon had an upgrade action tied to INITIAL_VERSION, which ran because initialization moved from version -1 to 0.
  • To fix this, Recon's initialization code now reads no version being present as the initial 0 version. The upgrade action tied to version 0 was merged into version 1's upgrade action, so it will still run if upgrading to this version from an old version before the versioning framework.

• Recon previously ran upgrade actions and apparent version increases in the same SQL transaction. This is no longer required after HDDS-15488. Recon upgrade actions should be idempotent #10442 which allows us to use shared ComponentVersionManager code for this.

What is the link to the Apache JIRA

HDDS-15374

How was this patch tested?

Unit tests for new Recon version manager added.