These layers, typically screen rotation layers, disable dimming because
the dimming result is baked into the layer (in the case of a screen
rotation, it's a screenshot of potentially-dimmed layers).

But cached layers are always rendered without the constituent layers
being dimmed, with the possibility of the entirety of the rendered
result being dimmed later. This means that layers that disable dimming
canot be cached. Otherwise, you have the following scenario:

1. HDR video is playing on an app like Youtube, with the surrounding UI
   dimmed.
2. Screen rotation starts. A screenshot is captured and replacing the
   screen contents.
3. The screen rotation animation takes a long time, so the screenshot is
   cached with another layer, such as a screen decoration layer. That
   whole cached set is *dimmed*, which means that the UI is doubly-dimmed and
   the HDR video is transiently dimmed, both of which causes a
   user-visible flicker during screen rotation.

There is an alternative approach of cleaning up this concept of
disabling dimming and rendering the screenshot as an extended sRGB
image, similar to HDR UI, but that requires changes to the screenshot
api to commmunicate the dimming ratio as well as changes to the screen
rotation code, and it's easier to fix the bug in caching instead :)

Bug: 325557704
Test: libcompositionengine_test
Test: Rotate the screen a lot during HDR playback
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f45ad66b536dddf01adef6613680360a5286b87b)
Merged-In: I184e221fa4431e4751002c7304bf89d2fe98fe20
Change-Id: I184e221fa4431e4751002c7304bf89d2fe98fe20