Add root/leaf distinction to tsh clusters

[webvictim]

Feature Request

tsh clusters doesn't give much useful information at the moment compared to the web UI (which tells you root vs leaf). It also doesn't immediately tell you at a glance what cluster you're logged into.

~ » tsh clusters
Cluster Name                  Status 
----------------------------- ------ 
ip-172-31-52-229-ec2-internal online 
ip-172-31-49-164-ec2-internal online 

Maybe we could improve it to something like this?

~ » tsh clusters
Cluster Name                  Status Cluster Type Active
----------------------------- ------ ------------ ------
ip-172-31-52-229-ec2-internal online root         
ip-172-31-49-164-ec2-internal online leaf         *

Could be a -v flag or just more information by default.

Motivation

Easier to use tsh from the command line.

Who's it for?

OSS User, Pro, Enterprise

[klizhentas]

great idea, we should do it in 5.1

[andrejtokarcik]

What is the preferred terminology here? The code seems to prefer to use the terms "local/remote cluster" for what the docs tend to call "root/leaf cluster".

[webvictim]

root and leaf is the preferred terminology now.

[andrejtokarcik]

This question from the associated PR doesn't seem to have been properly answered yet: When indicating the active cluster, should we prefer

Cluster Name                  Status Cluster Type Active
----------------------------- ------ ------------ ------
ip-172-31-52-229-ec2-internal online root         
ip-172-31-49-164-ec2-internal online leaf         *

or rather (similar to, e.g., tsh status)

   Cluster Name                  Status Cluster Type
   ----------------------------- ------ ------------
   ip-172-31-52-229-ec2-internal online root
>  ip-172-31-49-164-ec2-internal online leaf

[webvictim]

Personally I'd go with the second style to keep similarity with tsh status, but the decision is @benarent's.

[benarent]

We recently added something similar tsh kube ls can be used to select and obtain kubectl creds for Kubernetes clusters. I would use the same UX for consistency. As we expand this pattern of listing and selecting we should come back and review best practices for this specific pattern. Sorry for the delay on this and Happy New Year!

Example tsh kube ls

tsh kube ls
Kube Cluster Name        Selected
------------------------ --------
asteroid-sun.teleport.sh *
do-teleport-cloud
gke-teleport-cloud

Proposed Tweak to CLI UX

Cluster Name                  Status Cluster Type Selected
----------------------------- ------ ------------ ------
ip-172-31-52-229-ec2-internal online root         
ip-172-31-49-164-ec2-internal online leaf         *