feat: 'data:pg:migrate' command implementation (W-21303011)

[sbosio]

Summary

Here we implement a new data:pg:migrate interactive command that will allow customers to migrate Heroku Postgres Classic databases to the new Advanced tier.

There's some heavy refactor on this PR around (now shared) behavior between data:pg:create and the new data:pg:migrate command, given the latter needed a way to create an Advanced database as the target for a migration. Shared behavior was generalized and extracted to PoolConfig (in a similar way to what we did for data:pg:create and data:pg:update). While working on this we detected that we missed to copy the unit tests for that PoolConfig module from the NGPG plugin. We fix that here, plus add new tests for the extracted shared behavior.

Type of Change

Breaking Changes (major semver update)

• Add a ! after your change type to denote a change that breaks current behavior

Feature Additions (minor semver update)

• feat: Introduces a new feature to the codebase

Patch Updates (patch semver update)

• fix: Bug fix
• deps: Dependency upgrade
• revert: Revert a previous commit
• chore: Change that does not affect production code
• refactor: Refactoring existing code without changing behavior
• test: Add/update/remove tests

Testing

In order to test, checkout this branch, build the CLI and use the ./bin/run tool to run the command.

git checkout sbosio/ngpg-migrate
npm install && npm run build
./bin/run data:pg:migrate -a <test-app-name>

There are a few ways to configure a migration, but basically you'll need to have at least one legacy (non-Advanced) database created on your test app. Then you can use the interactive option to create a target database on-the-fly as the destination for the migration or you can have an Advanced database already created and available and select it as destination.

After the migration tooling is prepared, your migration config should be Ready for either starting or canceling the migration. When canceled, you'll need to start again the configuration and wait for preparation. If started, the migration should run until it completes.

The pair of databases (source and destination) that belong to a pending migration (any state between preparing and completed, failed or canceled) cannot be selected again as a source and destination for another migration. To test these scenarios you should have more than one legacy database on the test app to select as source.

Screenshots (if applicable)

Target selection

Migration config confirmation

Preparing migration after confirmation

Starting migration confirmation

Migration started

Related Issues

GUS work item: W-21303011

[k80bowman]

This looks great and, when I ran it through it's paces, worked perfectly.