Add WatchStreamExt::modify() to modify events

[aryan9600]

Motivation

Atm, we need to resort to nested maps if we want to modify the resource directly present in the Events returned by the watcher() stream.

let stream = watcher(api, watcher::Config::default()).map_ok(|ev| {
    ev.modify(|pod| {
        pod.managed_fields_mut().clear();
        pod.annotations_mut().clear();
        pod.status = None;
    })
});

Solution

Add WatchStreamExt::modify() which returns an EventModify stream. This allows for users to directly modify the inner value of an Event returned by the watcher stream, thus avoiding the usage of nested maps.

Example usage:

let stream = watcher(api, watcher::Config::default()).modify(|pod| {
    pod.managed_fields_mut().clear();
    pod.annotations_mut().clear();
    pod.status = None;
});

Fixes #1245

[codecov]

Codecov Report

Merging #1246 (85065c9) into main (db585dd) will increase coverage by 0.22%.
The diff coverage is 96.15%.

❗ Current head 85065c9 differs from pull request most recent head a58f446. Consider uploading reports for the commit a58f446 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1246      +/-   ##
==========================================
+ Coverage   72.60%   72.82%   +0.22%     
==========================================
  Files          72       73       +1     
  Lines        5899     5925      +26     
==========================================
+ Hits         4283     4315      +32     
+ Misses       1616     1610       -6     

Impacted Files	Coverage Δ
kube-runtime/src/utils/mod.rs	64.15% <ø> (ø)
kube-runtime/src/utils/watch_ext.rs	0.00% <0.00%> (ø)
kube-runtime/src/utils/event_modify.rs	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[clux]

Great work. Thanks a lot for this. One minor test request + have inlined a doc example after verifying locally.

[clux]

Looks great. Tyvm!

[nightkr]

Largely looks good to me! One more serious concern, but that's more about the existing Event::modify than about this PR.

[nightkr]

This looks like a bug in Event::modify if this passes, this should be vec![11].

[aryan9600]

its not a bug in Event::modify, its a shortcoming of matches!. this will always pass, since its not actually using restart_val (the compiler also complains about restart_val being unused) (ref: https://stackoverflow.com/questions/68155018/rust-matches-macro-behaves-unexpectedly-in-regards-to-enum)

fixed it by extracting the result and using an if guard to compare instead of directly specifying the desired value.

[nightkr]

Nit: No need to use poll! if you expect it to be Ready.

[aryan9600]

as far as i understand, the poll! here is used to get convert the future returned by ev_modify.next() into a Poll object.

[nightkr]

Yes, but since it should already be ready it would be equivalent to ev_modify.next().await. Then again, on second thought, poll! does have the advantage of failing faster if it's not ready for whatever reason.

[nightkr]

LGTM

That said, please try to avoid rebasing/squashing feature branches if possible, it makes reviews a pain.