core: omit invalid resource version parameters when doing paged requests

[goenning]

Motivation

Fix #1278

Solution

This is inspired by what client-go does, which means we don't set the resourceVersionMatch and resourceVersion when the continue param is defined.

I'm not sure if this covers all the scenarios, but it fixed the bug I was seeing.

As an example, if you change the pod_paged example to include .any_semantic(), the response will not be paged. With this PR the response would be paged as expected.

And as per your suggestion, I didn't implement this during the watcher paging loop because it's not exclusive to the watcher functionality, anyone paging with list would have this issue.

[codecov]

Codecov Report

Merging #1281 (086ef33) into main (d410464) will increase coverage by 0.12%.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

❗ Current head 086ef33 differs from pull request most recent head bc1aeac. Consider uploading reports for the commit bc1aeac to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1281      +/-   ##
==========================================
+ Coverage   72.66%   72.78%   +0.12%     
==========================================
  Files          75       75              
  Lines        6186     6196      +10     
==========================================
+ Hits         4495     4510      +15     
+ Misses       1691     1686       -5     

Files Changed	Coverage Δ
kube-core/src/params.rs	84.72% <100.00%> (+3.04%)	⬆️
kube-core/src/request.rs	98.74% <100.00%> (+0.02%)	⬆️

... and 1 file with indirect coverage changes

[clux]

Thanks a lot for this. Happy to merge this now, but leaving this for a few days in case of comments (also some overlap here with the watchlist pr).

[clux]

Oh, at least need a DCO fix on this @goenning . Deny issue is fixed in main.

[clux]

Going over this again just as a sanity; is this possibly slightly imprecise?

If resourceVersion is "0" with no limit, we end up NOT serialising resourceVersion which puts us in "Most Recent" semantics rather than "Any" semantics. Presumably this was not intended and the resourceVersion should be serialized above the first if?

[goenning]

Maybe we need to add a test for that too, but as per the snippet above, if rv=0 and the limit is unset, the resourceVersion is serialized.