CORE-6718 - Database reconciliation for member list

[nikinagy]

The member list topic was not backed by the DB on member side as we haven't had member persistence on member side. We had two approach to fix this: First approach is described here: https://r3-cev.atlassian.net/browse/CORE-6718 , but introduces more complexity and has many flaws as the data distribution could fail, especially since we likely won't have MGM info on member side in time to receive the data safely. Second approach is described here: https://r3-cev.atlassian.net/browse/CORE-6133 , which is a much simpler and fool-proof solution.

In this PR I went with the second approach.

Testing: Checked that we populated the member databases in dynamic networks:

Reconciliation test:

1. Deployed multi-cluster network.
2. Modified the data in hard-coded way for Alice to have updated data (updated the serial only) after registration:
3. Did the same in the database table to show that the version of the record has changed:
4. Did a lookup as Bob to see that Alice's info indeed got updated after the reconciliation:

[corda-jenkins-ci02[bot]]

Jenkins build for PR 6065 build 11

Build Successful: Jar artifact version produced by this PR: 5.2.1.0-alpha-1715251365761 Helm chart version produced by this PR: 5.2.1-alpha.1715251365761 Helm chart pushed to: oci://corda-os-docker-dev.software.r3.com/helm-charts/pr-6065/corda Helm chart Polaris score: 82

[driessamyn]

Can we have a design for this change please?

[nikinagy]

Can we have a design for this change please?

@driessamyn added https://r3-cev.atlassian.net/browse/CORE-20476 into our backlog as a follow-up that can be done in parallel while QA is testing the changes

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud