Fix auto-update re-exec arguments modified by aliases

[vapopov]

In this PR fixed issue related tsh {alias} if we define in alias same executable path of tsh, for instance:

~/.tsh/config/config.yaml

aliases:
  "loginvadym": ".build/tsh login --proxy=localhost:8443 --auth=local --user=vadym --insecure"

we don't spawn new process, instead just re-run the tsh main function with modified execution arguments

teleport/tool/tsh/common/aliases.go

Lines 205 to 221 in e50dae9

	// if execPath is our path, skip re-execution and run main directly instead.
	// this makes for better error messages in case of failures.
	if execPath == currentExecPath {
	log.Debugf("Self re-exec command: tsh %v.", arguments)
	return trace.Wrap(ar.runTshMain(ctx, arguments))
	}
	cmd := exec.Command(execPath, arguments...)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	log.Debugf("Running external command: %v", cmd)
	err = ar.runExternalCommand(cmd)
	if err == nil {
	return nil
	}

but in updater we use os.Args arguments, not modified ones by alias runner

teleport/lib/autoupdate/tools/updater.go

Lines 351 to 352 in e50dae9

	if err := syscall.Exec(path, append([]string{path}, os.Args[1:]...), env); err != nil {
	return 0, trace.Wrap(err)

this produce issue with updater, when it executed by alias

vpopov@Vadyms-MBP-2 teleport-docker % ./build/tsh loginvadym
Update progress: [▒▒▒▒▒▒▒▒▒▒] (Ctrl-C to cancel update)
ERROR: recursive alias "loginvadym"; correct alias definition and try again

discussion
Related: https://github.com/gravitational/cloud/issues/10053

changelog: Fixed client tools autoupdates executed by aliases (causes recursive alias error)

[Tener]

LGTM. After reading the issue analysis my first suggestion would be to move away from the global os.Args, so I'm happy to see this is indeed the fix.

Also, very cool feature 👍

Nit: perhaps worth mentioning this bugfix in the changelog? A bit of marketing for both features involved ;-)

[vapopov]

@hugoShaka could you please take a look when you have time

[hugoShaka]

Should we have a test covering the re-exec with alias mechanism? I'm worried someone might break it again in the future and won't detect it.