Proposal: Implement terrahub migrate command

[eistrati]

Describe the Proposal

Implement terrahub migrate command as a five phases process that should be executed sequentially:

1. START - start migration process for specific terrahub components using migrate workspace
2. PUSH - push current configuration by swapping between current workspace and migrate workspace for ALL .tfstate files and ONLY migration related .tfvars files
3. REVERT - revert previously executed terrahub push
4. VALIDATE - validate that current workspace is successfully migrated away from migrate workspace
5. CLEANUP - cleanup and remove everything related to migrate workspace

Expected Behavior

Without any changes to terraform configurations and/or terrahub components, we would like to be able to migrate resources that otherwise require downtime. For example: VPC and Subnets associated with Lambda function is NOT possible to modify unless Lambda is destroyed, then Subnet and last VPC is destroyed, after which we go back to build new VPC, then new Subnets, then new Lambda function. This process will require some kind of downtime.

On the other hand, without making any terraform changes, by executing terrahub migrate command we effectively duplicate resources for VPC and Subnets, build new Lambda function and swap between new .tfstate files and new .tfvars files for migrated resources, while using new .tfstate files with old .tfvars files for resources NOT in scope for migration.

It is NOT clear yet how other resources will behave, but overall goal of this new terrahub migrate command is to enhance some kind of lower to no downtime without any code changes.