oauth/api: drain timer channel on each iteration

[laurazard]

Fixes #5375

- What I did

Previously, if while polling for oauth device-code login results a user suspended the process (such as with CTRL-Z) and then restored it with fg, an error might occur in the form of:

failed waiting for authentication: You are polling faster than the specified interval of 5 seconds.

This is due to our use of a time.Ticker here - if no receiver drains the ticker channel (and timers/tickers use a buffered channel behind the scenes), more than one tick will pile up, causing the program to "tick" twice, in fast succession, after it is resumed.

- How I did it

The new implementation replaces the time.Ticker with a time.Timer (time.Ticker is just a nice wrapper) and introduces a helper function resetTimer to ensure that before every select, the timer is stopped and it's channel is drained.

- How to verify it

Reproduce as described in #5375

- Description for the changelog

Fix issue that will sometimes cause the browser-login flow to fail if the CLI process is suspended and then resumed while waiting for the user to authenticate.

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

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 87.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 60.97%. Comparing base (3826f5a) to head (60d0450).
Report is 13 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5376      +/-   ##
==========================================
+ Coverage   60.93%   60.97%   +0.03%     
==========================================
  Files         304      304              
  Lines       21348    21358      +10     
==========================================
+ Hits        13009    13022      +13     
+ Misses       7409     7407       -2     
+ Partials      930      929       -1     

[dvdksn]

works in my local test 🎉

[laurazard]

@thaJeztah @vvoland PTAL

[thaJeztah]

Thanks for updating! Left two comments 🙈

[thaJeztah]

Do we need to handle context.DeadlineExceeded here? We could even use the errdefs helper, but not sure if we want to import it here;

cli/vendor/github.com/docker/docker/errdefs/is.go

Lines 120 to 123 in 092b5f0

	// IsContext returns if the passed in error is due to context cancellation or deadline exceeded.
	func IsContext(err error) bool {
	return errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded)
	}

[laurazard]

Hmm, the purpose of that:

// if the caller canceled the context, continue
// and let the select hit the ctx.Done() branch

is just to make sure we hit the user canceled login error if the user cancels execution while API.getDeviceToken is going rather than the context canceled error from there, so I don't think we need it. This is also all inside /internal, so we don't expect others to import this, so I think it's fine. If the user does get a timeout while trying to connect to the tenant, I think we should error out and let them know.

[thaJeztah]

Ah, right; yeah, was curious if we wanted to retry if the connection timed out. I guess that would be a bit of an exceptional case, so returning early in that case makes sense as well.

Thanks!

[thaJeztah]

LGTM