Generally account for non-blocking channels

[shawkins]

Is your enhancement related to a problem? Please describe

There are several places where the client only accepts OutputStreams.

Describe the solution you'd like

Exec and log watch should accept WritableByteChannels as well and the code should handle the non-blocking case in a way that does not hold a thread

The initial changes for #4149 make the code aware of non-blocking, but will still hold the thread for the duration of the write.

Describe alternatives you've considered

No response

Additional context

No response

[shawkins]

To do this fully anywhere we accept an InputStream, you'd accept a ReadableByteChannel and a boolean blocking parameter, with a similar change for OutputStream. We need to know the channel blocking mode to understand if we can use a thread from the client threadpool to perform the operation.

Any operation involving the stream like CopyOrReadable should also have a non-blocking variant, for example:

CompletableFuture upload(ReadableByteChannel channel, boolean blockingMode);

The existing method would then be implemented roughly as:

default boolean upload(InputStream stream) {
  return upload(Channels.newChannel(stream), true).get();
}

Given all of our usages of streams, this will be quite a lot of work. So I'll first just address any inefficiencies in #4149, then we can determine a prioritization of where this may be most beneficial - logs, exec, file operations (such as copy), etc.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!