Revert "[CompositeAfterPaint, CompositeSVG] Add a repaint-only fast-path update"

This reverts commit 79a5b115074c48c8843e279f6fc81555fd360358.

Reason for revert: Reverting before M90 branchpoint as this is a large change.

Original change's description:
> [CompositeAfterPaint, CompositeSVG] Add a repaint-only fast-path update
>
> This patch adds a fast-path to PaintArtifactCompositor that skips
> compositing decisions and property tree updates for simple repaints.
> The important changes are:
> 1) PaintArtifactCompositor::UpdateRepaintedLayers now supports repaint
>    only updates for CompositeAfterPaint and CompositeSVG. This includes
>    logic such as issuing raster invalidations.
> 2) PaintArtifactCompositor::SetNeedsFullUpdateAfterPaintIfNeeded is run
>    after repaint and compares the old and new paint chunks and see if a
>    repaint-only update can be used.
>
> Microbenchmark results with 1,000 layers, one repainting each frame [1]:
>   Without CompositeAfterPaint: ~26s without patch, ~26s with patch
>   With CompositeAfterPaint: ~77s without patch, ~21s with patch
> [1] paint_perftest.cc in https://crrev.com/c/2648831/10
>
> PaintArtifactCompositor::UpdateRepaintedLayers has some complexity. When
> compositing decisions are made outside PaintArtifactCompositor, which is
> the common case pre-CompositeAfterPaint, it works the same as before
> this patch and simply calls UpdateLayerProperties for each repainted
> layer. When compositing decisions are made by PaintArtifactCompositor,
> which is used for CompositeAfterPaint and CompositeSVG, raster
> invalidations need to be issued in addition to UpdateLayerProperties.
> There are three complex steps:
> 1) Matching existing and repainted PaintChunks.
>    To ensure UpdateRepaintedLayers is O(|chunks|), we rely the fact that
>    repainted paint chunks are in the same order as the existing paint
>    chunks. Note that display items can be added or removed. The existing
>    paint chunks and newly repainted paint chunks are iterated over
>    simultaneously using the |PreCompositedLayerPaintChunkFinder| helper.
> 2) Updating the paint chunks and display items.
>    The paint chunks and display items for each PendingLayer need to be
>    updated to the repainted ones. This is done by swapping in the
>    repainted PaintArtifact onto the existing PendingLayer. The existing
>    paint chunk indices in the PendingLayer's PaintChunkSubset will be
>    unchanged (because the chunks are in the same order), but the chunks
>    themselves, and the display items, will be updated to the repainted
>    PaintArtifact.
> 3) Issuing raster invalidations.
>    Raster invalidation requires the repainted PendingLayer and the
>    existing cc::Layer (see: UpdateCcPictureLayer). The existing
>    cc::Layers are stored on PaintArtifactCompositor (e.g.,
>    content_layer_clients_) and are looked up from PendingLayers using
>    the same O(|layers^2|) approach that the full compositing update
>    uses (see: |ClientForPaintChunk|). Tests using a hash table that is
>    O(|layers|) were slower in practice.
>
> Bug: 1102866
> Change-Id: I82105a579c8620b6ef3f0ffbedb0d1be5a5f0cf0
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2648831
> Commit-Queue: Philip Rogers <pdr@chromium.org>
> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#856395}

Bug: 1102866
Change-Id: I83e9d69a1a2097343edb1cbed33575bae0e8401b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2714096
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Philip Rogers <pdr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#856749}