fix: force cli to exit after third sigint/sigterm

[Benehiko]

- What I did

Added a global signal handler for cases where context cancellation is not respected. This will force the CLI to exit after 3 attempts of sigint/sigterm.

⋊> ~/G/docker-cli on master ⨯ ./build/docker login 15:41:40Log in with your Docker ID or email address to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com/ to create one.You can log in with your password or a Personal Access Token (PAT). Using a limited-scope PAT grants better security and is required for organizations using SSO. Learn more at https://docs.docker.com/go/access-tokens/Username: ^C^C^Cgot 3 SIGTERM/SIGINTs, forcefully exiting

- How I did it

I register a go routine to catch further signals upon running a docker command. Docker plugin handling has its own signal handling and is excluded from this signal handler.

- How to verify it

Try with docker login since it's currently not respecting context cancellation.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.

Project coverage is 61.72%. Comparing base (70b53a0) to head (faf7647).
Report is 31 commits behind head on master.

Additional details and impacted files

@@ Coverage Diff @@## master #5171 +/- ##
==========================================
- Coverage 61.76% 61.72% -0.05% 
==========================================
Files 297 294 -3 Lines 20768 20772 +4 ==========================================
- Hits 12828 12822 -6 - Misses 7024 7034 +10 
Partials 916 916 

[krissetto]

maybe we should also add a basic test case for this

[laurazard]

I had another idea, let me know what you think!

[krissetto]

Totally non blocking, just food for thought..are we sure we want to exit with status 1 when the user decides to forcefully exit?

It could make sense to start differentiating expected status codes from totally unexpected failures, in order to be able to distinguish them from a tracing/metrics perspective as well.

[Benehiko]

I think forcefully exiting the CLI like this should be considered a problem. It means that the process the user cancelled did not cancel the first time through context.Done().

[vvoland]

LGTM, thanks!