Cleanup of rancher server command

[enrichman]

Fixes rancher/rancher#44374

This PR contains the refactor of the #347.
The panics fix where added with #348

Description

Fixing the panics I took the opportunity to cleanup a bit the code (only the server command, to avoid a huge and "critical" refactor). The server command is pretty safe to play with.

Also some deprecated deps were updated (terminal and ioutil).

1) Common validation

The server commands are expecting a valid server configuration:

func validateServersConfig(cnf config.Config) error {
	// do validation validate
}

This common validation was changed to a cli.BeforeFunc and added in the Before of the server commands.

2) Testing

To make test possible I moved the business logic to their dedicated func, dropping (when possible) the dependency from the cli.Context.

I.e.: the ServerCurrent now accept an io.Writer and a *config.Config. Or the ServerSwitch now needs only the *config.Config and the serverName. This made test possible (and tests were added).

3) Centralized Config

The *config.Config is needed by every commands, and loaded every time in the same (?) way. This can be done only once at the very start of the root command, in the BeforeFunc. Then the Config can be just passed as a dependency to the commands.

Be aware that to make this work a pointer has to be passed downward, and update the underlying struct in the Before. This is because in Go arguments are passe by value, and the Commands are built before the actual Run (obviously). So the pointer will be always the same, but it will point to the just loaded conf.

conf, err := config.LoadFromPath(path)
if err != nil {
	return err
}
*cfg = conf

With this approach we can drop all the loadConfig in every command:

// not needed anymore
cf, err := loadConfig(ctx)
if err != nil {
	return err
}

4) Simplifications

Some minor cleanup, like the getServers(cfg *config.Config) []*serverData func.
Instead of getting the ordered keys, and then loop through them we can simply use the already existing serverData struct.

This will return an ordered slice of serverData that will be used by the server prompt selection, and also by the ServerLs, that was using an unordered set of servers (now it's consistent).

[JonCrowther]

Overall looks very good, just a couple questions for my understanding.

[JonCrowther]

This LGTM. Thank you for adding the changes I suggested!

[crobby]

lgtm, happy to see some tests in here!