rgwlc: remove explicit lc shard resets at start-of-run

rgwlc: remove explicit lc shard resets at start-of-run

This is an alternative solution to the (newly exposed) lifecycle
shard starvation problem reported by Jeegen Chen.

There was always an starvation condition implied by the
reset of lc shard head at the start of processing.  The introduction
of "stale sessions" in parallel lifecycle changes made it more
visible, in particular when rgw_lc_debug_interval was set to a small
value and many buckets had lifecycle policy.

My hypothesis in this change is that lifecycle processing for each
lc shard should /always/ continue through the full set of eligible
buckets for the shard, regardless of how many processing cycles might
be required to do so.  In general, restarting at the first eligible
bucket on each reschedule invites starvation when processing "gets
behind", so just avoid it.

Fixes: https://tracker.ceph.com/issues/49446
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
(cherry picked from commit 6e2ae13adced6b3dbb2fe16b547a30e9d68dfa06)

rgwlc: add a wraparound to continued shard processing

If the full set of buckets for a given lc shard couldn't be
processed in the prior cycle, processing will start with a
non-empty marker.  Note the initial marker position, then
when the end of shard is reached, allow processing to wrap
around to the logical beginning of the shard and proceeding
through the initial marker.

Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Please enter the commit message for your changes. Lines starting
(cherry picked from commit 0b8f683d3cf444cc68fd30c3f179b9aa0ea08e7c)

don't report clearing incorrectly

Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>