Require database exists if migration is enabled

[fbac]

Require the database to exist when the migration server is enabled by triggering namespace derivation and namespaced DB initialization in main.main

Update main.main to broaden the conditional that gates namespace derivation and database initialization to also include options.MigrationServer.Enable alongside the existing Replication, Sync, and Indexer checks in main.go.

📍Where to Start

Start at the conditional in main.main in main.go that gates namespace derivation and namespaced database initialization.

Changes since #1074 opened

• Added required field validation for signer private key when migration server is enabled [2b93b22]

---

Macroscope summarized 2b93b22.

[graphite-app]

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• Queue - adds this PR to the back of the merge queue
• Hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[mkysel]

this means that the migrator needs to have the Signer.PrivateKey of the node. Otherwise we will compute a different namespace. Do we want to pass this info around?

[fbac]

It's needed, as the migrator has to sign envelopes PayerEnvelope and OriginatorEnvelope both.

[mkysel]

do we expect to have a separate payer key for this? Or are we reusing the node key?

[fbac]

Separate payer key, already set up in testnet. That way we can properly identify the migrator "payer" if needed.

[mkysel]

the migrator has to share the DB With the sync and API nodes, right?

			if namespace == "" {
				namespace = utils.BuildNamespace(
					options.Signer.PrivateKey,
					options.Contracts.SettlementChain.NodeRegistryAddress,
				)
			}

So, to correctly determine the DB to share, it must have the same options.Signer.PrivateKey as the other services.

I guess it's okay if we have to provide both the node key and the payer key to the migrator. It just needs to be configured in the infra.

[mkysel]

the signer.private key should be checked in validateMigrationOptions

[fbac]

Yes, that's done. Maybe I explained myself wrong.
The migrator has two keys:

• Separate payer key, to properly identify the migrator as an unique payer. Signs PayerEnvelopes.
• Node private key, which currently is the same as node 100. It's the same key where the payer runs, and the infra reflects this. Signs OriginatorEnvelopes.

[mkysel]

makes sense. Can you add these keys to validateMigrationOptions? Approving otherwise

[fbac]

Added.