With shared images and, we will (eventually) not track a cleared rect, just keeping a single "cleared" bit. OneCopyRasterBufferProvider uses RasterInterface::CopySubTexture, whose implementation currently has to deal with optimizing the clear rects because OneCopyRasterBufferProvider might be splitting the copy when the workaround is active. As we are moving to a model where CopySubTexture would be atomic, this would mean a split CopySubTexture would have to pessimistically clear the texture on the first blit, defeating the purpose of the workaround, at least for the first blit on a new tile.

Ideally we could manage max_copy_texture_chromium_size entirely service-side. Relevant historical bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=498443
https://bugs.chromium.org/p/chromium/issues/detail?id=542478

Options are:
1- add a scope to allow non-atomic CopySubTexture.
2- move the logic service side, i.e. just do a loop like:
while (rows_to_copy) {
  Copy();
  glFlush();
}
3- same as 2, but add a way to yield to the scheduler in each loop iteration

(1) would keep the workarounds functional, but add even more complexity.
(2) would keep the workaround for the case in bug 542478, but basically disable it for the case in bug 498443
(3) again adds back some complexity, but would restore functionality.

It's not entirely clear if bug 498443 is still relevant. We should probably experiment to get an idea.