Cleanup ssh tunnels on cancel

[m-lima]

Details
In pkg/minikube/tunnel/kic/ssh_tunnel.go the interrupt signal is caught and it stops the LoadBalancerEmulator. However, it assumes that the interrupt will also propagate to the children ssh tunnels, which are running in a goroutine inside startConnections.
The interrupt, however, kills the goroutine and the blocking call which waits for the child process to finish. This leaves the ssh tunnels dangling.
On the other hand, if CTRL + C is sent on the same terminal as minikube tunnel and the clean-up routine included killing all ssh tunnels, the OS would error with "process already finished".

This leads to accumulation of processes and is likely to happen. Since minikube tunnel is a blocking command, users will tend to detach it from the terminal and kill it with a SIGINT (as proposed in #3647).

Approaches
There are two proposed approaches. This PR takes the approach of having the tunnel know if is running or not. The second approach is to have the parent of all connections managed and know which processes should be killed.

The first approach, proposed with this PR, also addresses #8511, by letting the process owner hold the knowledge if the process is running or not. Since the ssh tunnels are started inside startAndWait() on pkg/minikube/tunnel/kic/ssh_conn.go, and a blocking call to Wait() is made, the owner can know when the process is started, finished, or killed.

The second approach is more oriented towards the cleaning up of the ssh tunnels, and isolates changes to only pkg/minikube/tunnel/kic/ssh_tunnel.go. However it relies on sync. The second approach can be seen here: https://github.com/m-lima/minikube/tree/issue/10752-managed-kill

Output
With this PR, users will be notified of connections being closed (as opposed to the silent death that happens now). E.g:

$ minikube tunnel
🏃  Starting tunnel for service serviceA.
🏃  Starting tunnel for service serviceB.
🏃  Starting tunnel for service serviceC.
^C✋  Tunnel for service serviceB stopped.
✋  Tunnel for service serviceA stopped.
✋  Tunnel for service serviceC stopped.

Also, when detaching from the terminal, all ssh tunnels will be reaped, also outputting to the terminal (if not redirected by the user). E.g:

$ minikube tunnel
🏃  Starting tunnel for service serviceA.
🏃  Starting tunnel for service serviceB.
🏃  Starting tunnel for service serviceC.

On another terminal:

kill -INT <PID>

Main terminal:

✋  Stopping tunnel for service serviceA.
✋  Stopping tunnel for service serviceB.
✋  Stopping tunnel for service serviceC.

fixes #10752

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: [email protected]

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-ci-robot]

Hi @m-lima. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: m-lima
To complete the pull request process, please assign ilya-zuyev after the PR has been reviewed.
You can assign the PR to them by writing /assign @ilya-zuyev in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[m-lima]

This PR is the same as the closed #10753
This was an attempt to get CLA validation

[minikube-bot]

Can one of the admins verify this patch?

[m-lima]

Can someone help me with the CLA?
It is signed. The email is the one from the commits. The name also matches the author name for the commit.
If you have access to the LinuxFoundation contact pages, this is my user: https://identity.linuxfoundation.org/user/509293

I have tried /check-cla, rebasing and pushing to force a re-run, closing my previous PR and opening a new one.
I'm out of ideas.
Any help would be appreciated

[medyagh]

@m-lima
do mind sharing

$ git config user.name
$ git config user.email

are they same as the one that u used in the CLA signing ?

[m-lima]

@m-lima
do mind sharing

$ git config user.name
$ git config user.email

are they same as the one that u used in the CLA signing ?

$ git config user.name
Marcelo Lima # same as my Linux Foundation "Full Name"
$ git config user.email
marcelo wind at gmail # same as Linux Foundation email

Note that the user.name is not my github/linux foundation user ID. It is my Linux Foundation "Full Name".
Is this the issue? Should I change the user.name to be my Linux Foundation user ID?
I'll give this a try now

[m-lima]

/check-cla

[m-lima]

@m-lima
do mind sharing
$ git config user.name
$ git config user.email
are they same as the one that u used in the CLA signing ?

$ git config user.name
Marcelo Lima # same as my Linux Foundation "Full Name"
$ git config user.email
marcelo wind at gmail # same as Linux Foundation email

Note that the user.name is not my github/linux foundation user ID. It is my Linux Foundation "Full Name".
Is this the issue? Should I change the user.name to be my Linux Foundation user ID?
I'll give this a try now

Updated the author name from "Marcelo Lima" to "m-lima". Still can't validate CLA

[medyagh]

@m-lima c maybe try to recreate the PR with the new git config ?

[medyagh]

does the email say marcelo wind at gmail (with word at? instead of @ ?) that could be the problem

[medyagh]

@m-lima would u like to close this PR and reopen again when CLA is fixed?

[medyagh]

/check-cla

[m-lima]

@m-lima would u like to close this PR and reopen again when CLA is fixed?

I can do that. I just don't know what to do to fix the CLA, though. This is why I was asking for help. I tried everything I could think of and everything suggested so far :(