Identities authentication can use a bit of delay before opening up the browser to allow user to read the instructions

[CMCDragonkai]

Specification

It's possible to easily miss the required instructions for authenticating to an identity provider.

I suggest that the instruction text must be written out, and then we wait 1 second before opening up the browser.

Right now the full text looks like this:

Navigate to the URL in order to authenticate
Use any additional additional properties to complete authentication
url     	https://github.com/login/device
userCode	058C-EF16
Authenticated digital identity provider github.com
identityId	CMCDragonkai

Those messages added in needs to be put into the STDERR, not in the same STDOUT output to avoid pipe composition problems.

Replace these lines:

Navigate to the URL in order to authenticate
Use any additional additional properties to complete authentication

With:

Navigate to the URL and use the properties to complete authentication.

So at this point:

Navigate to the URL and use the properties to complete authentication.
url     	https://github.com/login/device
userCode	058C-EF16

Delay by 1 second before opening up the browser.

I also think interactive output - that is to terminal can be detected, and additional flourishes can be added afterwards. Specifically things like a terminal progress bar - basically anything that has a time limit and may expire should have something like a progress bar/countdown timer that sort of updates on the same line to indicate to the user is time is running out.

Tasks

1. Ensure that help text goes to STDERR
2. Fix up the help text - progress text
3. Delay by 1 second before opening up the browser

[linear]

ENG-396 Identities authentication can use a bit of delay before opening up the browser to allow user to read the instructions

[CMCDragonkai]

BTW the usage of STDERR for "info messages" is well understood. We obviously use STDERR for all the formatted error output, but we haven't really beeng using it for any progress. Progress of course is indicated through log messages atm - primarily inside the agent logs. But individual commands can make use of STDERR for progress information intended for the end user.

I think it would be interesting to use STDERR to show progress bars and other information. The terminal would thread them together.

Buffering: Another factor is how the streams are buffered. stdout is often line-buffered, meaning it waits until a newline character or the buffer is full before sending data to the terminal. stderr, however, is typically unbuffered and prints output immediately. This difference can also contribute to the apparent interleaving of messages.

So basically it should be possible to provide some informational messages in the STDERR, then write out a newline, to then allow the STDOUT to output the full line properly. Ideally stdouts should be pipeable and processable even in human layouts.

[CMCDragonkai]

This has good comments https://unix.stackexchange.com/questions/331611/do-progress-reports-logging-information-belong-on-stderr-or-stdout, that we should in fact be explicitly flushing when the stdout is being redirected, to ensure that things like log files are properly being updated.