Drop preview failure notification during destruction

Changes from https://crrev.com/c/1825661 ensured PDF compositor
failures are propagated to the print preview UI.  A new crash scenario
is from trying to propagate a failure notification being made when the
enclosing tab is already being closed.

Managed to reproduce the crash by introducing in a developer build a
long delay in PdfCompositorImpl::HandleCompositionRequest() (of several
seconds).  This allows for a human to time the destruction of the
window at a time when the PDF compositor is active.

Resolve by dropping the failure notification if the associated web
contents is known to be destroyed or in the process of being destroyed.

Bug: 1011583
Change-Id: I9dea997c00c3c117ae144ad21b7a5c82f0f569c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1848433Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Alan Screen <awscreen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#704340}

chrome/browser/ui/webui/print_preview/print_preview_handler.cc

@@ -1138,6 +1138,10 @@ void PrintPreviewHandler::OnPrintPreviewReady(int preview_uid, int request_id) {
 }
 
 void PrintPreviewHandler::OnPrintPreviewFailed(int request_id) {
+  WebContents* initiator = GetInitiator();
+  if (!initiator || initiator->IsBeingDestroyed())
+    return;  // Drop notification if fired during destruction sequence.
+
   std::string callback_id = GetCallbackId(request_id);
   if (callback_id.empty())
     return;