Adjusted TaskListener flushing in remote code

[jglick]

Amends #3563 a bit. See discussion in jenkinsci/workflow-api-plugin#81. There are several changes here:

• A StreamTaskListener created on the master does not set the PrintStream.autoFlush flag. So why would we do so on the remote side? That merely produces a flurry of ProxyOutputStream.Flush packets. We expect that code flushes a stream when it is done with it. In fact from 2.121.x → 2.138.x for freestyle builds running Shell I see introduced flush packets, from [JENKINS-52729] Launcher.ProcStarter.stdout(TaskListener) discards remotability #3563 I presume, which this PR corrects again.
• Conversely, RemoteLaunchCallable on the agent side produces a LocalLauncher which produces a LocalProc which uses StreamCopyThread to forward stdout/stderr of the process. Yet as far as I can tell, this never flushed its sink unless you pass the closeOut flag (which no code in core does), meaning the tail end of log output could be lost if the sink were buffered. Freestyle builds have unbuffered logs, so probably this never mattered, but for JEP-210 I am finding that some buffering for Pipeline with local log storage is useful for performance reasons, and definitely for cloud log storage it is expected. Launcher is not used in this way for durable tasks like sh, but various SynchronousNonBlockingStepExecutions (and thus also SimpleBuildSteps) use it.
• Making sure that it is easy for a LineTransformationOutputStream to handle flush properly. Otherwise a flush on top of a stack of decorated loggers can get lost.
• Some ConsoleNote Javadoc related to JEP-210.

Proposed changelog entries

• Adjusted stream flushing behavior for code running remotely on agents.
• Developer: introduced LineTransformationOutputStream.Delegating.

[dwnusbaum]

We expect that code flushes a stream when it is done with it

That expectation seems reasonable and preferable to the current behavior, but given that this code has been unmodified since 2007 I am a little concerned that this may break things. Should be easy enough to fix if it does cause issues, but I do not have a good sense of whether there may be widespread impact.

[jglick]

given that this code has been unmodified since 2007 I am a little concerned that this may break things

Indeed. Of course that is true of a lot of Jenkins code.

[jglick]

I want to do some testing of this and sleep on a bit more before pushing into releases.

[dwnusbaum]

Latest changes look good to me. Do you plan to add any tests here, or just do some manual testing of various affected scenarios?

[jglick]

Do you plan to add any tests here

TBD.

or just do some manual testing

Have done some sanity checks so far, but deserves more.

[jglick]

Note to self: need to document expected caller usage of remoted TaskListener.

[oleg-nenashev]

LGTM

[jglick]

This just turned into a grab bag of JEP-210-related patches which would be better refiled separately.