Don't check that we always have direct compositing available

It is totally possible that we now fallback to kBitmap for especially
large canvases. We've been save from this check because Skia usually
fails as well, so ResourceProvider is nil. A fuzzer found a situation
where Skia doesn't *quite* fail, but we're still falling back to
kBitmap.

Bug: 1013933
Change-Id: I5aa2f4bb0a85cbe1013edaba43183f1e866b00c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1884651Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Aaron Krajeski <aaronhk@chromium.org>
Commit-Queue: Aaron Krajeski <aaronhk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#710300}

third_party/blink/renderer/core/offscreencanvas/offscreen_canvas.cc

@@ -375,15 +375,6 @@ CanvasResourceProvider* OffscreenCanvas::GetOrCreateResourceProvider() {
         FilterQuality(), context_->ColorParams(), presentation_mode,
         std::move(dispatcher_weakptr), false /* is_origin_top_left */));
 
-    // The fallback chain for k*CompositedResourceUsage should never fall
-    // all the way through to BitmapResourceProvider, except in unit tests.
-    // In non unit-test scenarios, it should always be possible to at least
-    // get a ResourceProviderSharedBitmap as a last resort.
-    // This CHECK verifies that we did indeed get a resource provider that
-    // supports compositing when one is required.
-    CHECK(!ResourceProvider() || !HasPlaceholderCanvas() ||
-          ResourceProvider()->SupportsDirectCompositing());
-
     if (ResourceProvider() && ResourceProvider()->IsValid()) {
       ResourceProvider()->Clear();
       // Always save an initial frame, to support resetting the top level matrix