When the ChangeFrontier processor for a changefeed is started up, it
creates a spanFrontier to track the overall progression for the feed.
Each watched span is set to the empty timestamp so we can tell the
difference between a rangefeed being behind and one still initializing.

However, rangefeed will happily return resolved timestamps less than the
one it was started with. If we feed this into the spanFrontier, it can
report a timestamp behind the one everything started up at. In the case
of a new changefeed, this is fine (though perhaps odd). In the case of a
changefeed being restarted from the job's high-water, this means we can
overwrite the high-water progress with the lower value, regressing it.
At the least, this is very surprising UX, but it's easy to argue that
it's a correctness issue.

Touches cockroachdb#36879

Release note (bug fix): Fixed a bug where `CHANGEFEED` job progress
would regress when the job was restarted.

I was surprised that rangefeeds would return resolved timestamps from
before the request timestamp and this expectation mismatch was a
component in a changefeed bug. It's not clear yet if the contract is
wrong or simply underdocumented, so document it louder for now and leave
a TODO to reconsider the contract when rangefeeds have more users.

Also a very small cleanup on the `(*DistSender).RangeFeed` api while I'm
in here.

Release note: None