Update telemetry to support command-remapping

[marckhouzam]

What this PR does / why we need it

This PR adapts the telemetry logic to respect command-remapping of plugin commands.

The important changes are as follows.

1- The telemetry plugin command-tree (~/.cache/tanzu/plugins_command_tree/command_tree.yaml) is no longer built when a plugin is installed, but when the plugin is first invoked. This is because the new logic needs to find the cobra command that has been created for a remapped command, and this cobra command does not exist yet when the plugin is being installed.

2- The telemetry plugin command-tree was previously only showing the sub-commands of a plugin. This is no longer sufficient because a plugin can remap a command to be outside its own command-tree path. For example the resource plugin provides a tanzu deploy command which is clearly not under the tanzu resource command-path. To fix this, this PR build the telemetry command-tree in such a way that it includes the entire, remapped, hierarchy of the commands provided by a plugin. For example, for the resource plugin, we would see both the deploy and the resource commands at the first level of that plugin's command-tree.

3- The telemetry plugin command-tree did not previously include targets (e.g., operations). This was fine because the command-tree represented sub-commands of the plugin, and when telemetry was gathered when a command was typed, it could ignore the target. This is no longer working because when collecting telemetry, we need to start from the exact command-path that the user typed because we need to accept remapped commands; and this user input sometimes has the target present.

4- When determining aliases for a command, we now need to account for remapped command and for such cases, map the user input to the how the command can be invoked directly in the plugin. For example, when looking for aliases for tanzu deploy, we need to call <resource_plugin_binary> deploy and this mapping is not always this straight forward. This PR therefore looks for the cobra command that is invoked by what the user typed, and uses a new annotation to know how to map it back to a plugin invocation. Note that it would have been possible to invoke the tanzu CLI directly to print the help of a plugin command and let it do the remapping automatically; the problem however, is that the CLI is much slower than calling a plugin directly (due to its overhead), so building the command-tree becomes very slow. This PR therefore continues to call the plugin binary directly to invoke the help of the plugin's different command to obtain any aliases.

5- Backwards-compatibility: because the telemetry plugin command-tree is different than the one built by older CLIs, it would affect telemetry of those older CLIs, when running them after having run the new CLI with the new command-tree format. To avoid this, this PR changes the location of the command-tree from command_tree.yaml to command_tree_v2.yaml. With this change, both the new CLI and the older ones can be used alternatively and they will each have their own command-tree with its own format.

Which issue(s) this PR fixes

Fixes # N/A

Describe testing done for PR

I tested the following cases:

1. doing a tanzu plugin install --group vmware-tanzu/plugin-engineer with the Asteroid versions and seeing that all plugins get installed, but that no plugin tree gets created yet
2. doing a tanzu plugin clean and seeing the new cache and old cache are cleared (the directory is removed), then rebuilding the command-tree one plugin at a time
3. doing a tanzu plugin uninstall acceleratorv2 and seeing that the command-tree for that plugin only was removed
4. Running each plugin and made sure there was no error generating the command-tree in command_tree_v2.yaml for each one:

tz accelerator -h
tz ops apply -h
tz apps -h       
tz build -h      
tz ops cluster -h     
tz cluster-group -h
tz ops clustergroup -h
tz domain -h
tz domain-binding -h
tz egress -h
tz package -h
tz project -h
tz role -h
tz resource -h
tz route -h
tz secret -h
tz services -h
tz space -h
tz workflow -h

# Using aliases
tz project ls
tz apps config nse delete -h

1. Looked at the content of the telemetry database while running different commands:

# Core command
tz context list
# global plugin
tz space list
# k8s plugin
tz secret -h
tz k8s secret -h
tz kubernetes secret -h
# ops plugin
tz ops clustergroup
tz operations clustergroup
# Remapped commands
tz cluster -h
tz cluster uncordon -h
tz deploy -h
tz role binding list -h
tz role bind Administrator

1. Looked at the content of the telemetry database while running different commands with tanzu CLI version 1.5.1:

# Core command
tanzu context list
# global plugin
tanzu space list
# k8s plugin
tanzu secret -h
tanzu k8s secret -h
tanzu kubernetes secret -h
# ops plugin
tanzu ops clustergroup
tanzu operations clustergroup
# Remapped commands
tanzu cluster -h
tanzu cluster uncordon -h # this one didn't catch the uncordon because remapping isn't handled in old CLIs
tanzu deploy -h
tanzu role binding list -h # this one didn't catch anything after "role" because remapping isn't handled in old CLIs
tanzu role bind Administrator # this one didn't catch anything after "role" because remapping isn't handled in old CLIs

Release note

Update the telemetry logic to support command-remapping

Additional information

Special notes for your reviewer

[vuil]

This is a really nice set of changes, thanks!
Minor comment nit.
Also a few typos in the PR description

near "how the command can be invoked"
because very slow -> becomes very slow

finally some questions about behavior of an old CLI using the new command tree format.

[prkalle]

Thanks for changes. Nicely done!
Looks good at the first pass. I will do some testing and update if I find any issues/comments

[vuil]

thanks for the prompt updates, lgtm!