changefeedccl: ExportRequest poller should poll ranges instead of all spans

[danhhz]

Currently, it picks a new high-water timestamp, then polls all tracked spans between the old high-water and the new one. In the cdc/w=1000/nodes=3/init=false roachtest, we usually see each poll finish in tens of seconds, but occasionally see one or two that take 4 minutes or more. Then the next poll has even more data to export than usual, which seems to increase the likelihood of hitting a slow request again. This is currently the biggest stability issue of the tpcc-1000 test.

Now that span-frontier is plumbed and we have span-level resolved timestamps, we can use it to rework the poller. For example, every range gets a request put in a queue. A bounded set of workers pull a request from the queue, wait for it to come back, put the data and resolved timestamp in the buffer, and then re-enqueue the same span with the next set of timestamps. There could be some coordination for what the next highwater is between all the requests, but it's easier and end-to-end latencies will be lower if there isn't (incidentally, the latter also might help find some bugs that will be triggered when we switch to RangeFeed).

[danhhz]

I thought we'd need this to rein in the long tail, but it's possible that #32060 was actually the issue I was seeing in the roachtests. It's a pretty big change to how poller works, so I'm going to optimistically move this out of 2.1.x, but with the caveat that additional testing may pull it back in.

[danhhz]

This was a speculative idea and we still haven't seen any evidence from our testing that's it's needed. Plus RangeFeed obsoletes it. Closing