Change Api::log_stream to return AsyncBufRead

[aryan9600]

Motivation

The current log_stream implementation returns a stream of bytes that aren't newline buffered. This can cause a visual mess, when for example, there are multiple log lines in one chunk of the stream.

Solution

Modify kube_client::api::subresource::Api::log_stream() to return an async buf reader (futures::io::AsyncBufRead) that can read logs asynchronously. Users can call call .lines() on it to get a newline buffered stream of logs.

Fixes #1160

[clux]

this looks sensible to me at a quick look. thanks for tackling this.
some quick comments.

[codecov]

Codecov Report

Merging #1235 (ae6b9ee) into main (bd14267) will increase coverage by 0.00%.
The diff coverage is 90.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1235   +/-   ##
=======================================
  Coverage   71.93%   71.93%           
=======================================
  Files          71       71           
  Lines        5725     5727    +2     
=======================================
+ Hits         4118     4120    +2     
  Misses       1607     1607           

Impacted Files	Coverage Δ
kube-client/src/client/mod.rs	70.52% <75.00%> (-0.25%)	⬇️
kube-client/src/api/subresource.rs	51.96% <100.00%> (ø)
kube-client/src/lib.rs	93.78% <100.00%> (ø)

... and 1 file with indirect coverage changes

[nightkr]

I think this is one of those cases that makes sense and we should make it easy.. but we shouldn't make it required.

If you're writing a tail for a single container then you'd probably want to stream in all data as soon as it becomes available, whereas if you're trying to merge the output of multiple then line-buffering would probably be less confusing.

It would probably be possible to have a .lines() combinator of some kind on the impl Stream<Item = Result<Bytes>> returned by request_text_stream()

[Dav1dde]

Is it not possible to expose a AsyncRead or better AsyncBufRead, instead of a stream, which would give us .lines() for free?

[nightkr]

I think that would be ideal, yes.

[aryan9600]

changed the implementation to return an AsyncBufRead 👍

[Dav1dde]

Even if I think these are good changes, it's now a breaking change. @clux

[aryan9600]

don't know why clippy is complaining, these changes don't touch any of the reported code blocks.

[Dav1dde]

don't know why clippy is complaining, these changes don't touch any of the reported code blocks.

Unlucky timing, nightly must have added more lints, see #1238

I'll try to get them fixed separately, you can just ignore them here

[clux]

LGTM now. Have left a minor doc suggestion, and leaving open for David.

[Dav1dde]

I like the changes, I had some ideas for the docs, let me know what you think.

Also I think we should rename request_text_stream since we're already breaking the API.