Adding node-extensions support in CLI

[g4ndr4]

Context

The aim of this PR is to add support for node-extension related operations to CLI.

• A new command group node-extensions is being added, with two new commands
• node-extensions init - used to init node_extensions section of tenderly.yaml file, similar to how actions are being initialized
• node-extensions deploy - used to deploy either a specific extension, or all extensions in tenderly.yaml file

node-extensions init command

This commands helps users initialize extensions in the tenderly.yaml file.
It accepts the following arguments:

• name - used to specify extension name
• description - used to specify extension description
• methodName - used to specify extension method name

The command checks whether the provided methodName is valid, and then prompts the user to select one action from a list of those eligible for extensions (presented in the following format: account/project:action).
The list will contain only actions that are not already used by other extensions in tenderly.yaml file.
If there are no actions, eligible for extensions, found in tenderly.yaml, the command will return an error.
If there are eligible actions in tenderly.yaml, but all already used for other extensions in tenderly.yaml, the command will return an error.

Once the user has picked an action, the command will check whether the chosen extension method name is already taken by another extension in the same account/project and, if so, return an error.

Otherwise, the command will add the extension to the tenderly.yaml.

node-extensions deploy command

This command deploys extensions specified in tenderly.yaml file.
It accepts the following arguments:

• account - used to specify which account the extension is defined for in tenderly.yaml
• project - used to specify which project the extension is defined for in tenderly.yaml
• extensionName - used to specify which extension in the provided account/project should be deployed

If no arguments are provided, the command will attempt to deploy all extensions defined in tenderly.yaml. In case any of those extension deployments fail, it will print out the failure reasons and continue with deployment.

The deployment of an extension has two steps. In case there are multiple extensions being deployed, these same steps are repeated for each extension being deployed.

1. Validation

This step performs the following checks:

• Is the extension method name valid
• Is the extension method name already in use by another extension in the same account/project
• Is the extension action deployed in the backend
• Is the extension action in use by another extension in the same account/project

If any of these checks fail, the deployment of the extension won't go through. Results of all four checks are aggregated and presented to the user in an error message.

2. Deployment

This step deploys the extension to the backend.
It executes only if the Validation step succeeds.

[g4zyn]

My code structure would look something like this:

tenderly-cli/
 - main.go
 internal/
  command/
   - builder.go
   - command.go (types/interfaces)
   w3a/ (actions)
   gateway/ (extension commands should be inside this package since they belong to gateway domain) 
   hardhat/
   ...

Focus more on grouping logic by domain and exposing more interfaces.
Avoid things like:

• common.go, util.go ...
• model package (models should be inside domain packages, everything action related should be placed in action package and you should have only one package named action)
• global variables (sometimes it’s useful for default configurations for example, but mutating that variable should be avoided. Focus on exposing more functions and interfaces)
• camel-cased file naming, use snake-case instead

@l2cup 's PR on restructuring tenderly-server is a good example of how things should be structured.

I didn't have time to dive into the implementation itself, but with right code structuring you'll be able to write cleaner and more manageable code.