Do not handle Dart isolate messages if the isolate is being shut down

[jason-simmons]

This fixes a race that can happen if Dart invokes an isolate's message handling callback during isolate shutdown. The callback installed by Tonic will invoke a dispatcher set by the engine's DartIsolate::SetMessageHandlingTaskRunner, which will queue a message handling task to the designated task runner.

If the queued task runs after DartIsolate::Shutdown has been called, then Tonic's DartMessageHandler::OnHandleMessage will fail when it tries to enter the isolate.

DartIsolate will set a shutdown flag on the DartState when Dart invokes the isolate's shutdown callback. Tonic can avoid this race by checking that flag before proceeding with message handling.

Fixes flutter/flutter#160003

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[gaaclarke]

@chinmaygarde friendly ping. The code looks good but it's hard to know if there are any potential ramifications we aren't considering. If we are unsure we should take a cue from the tests and accept it.

[gaaclarke]

(Also obligatory call for a test)

[jtmcdole]

Monorepo Migration Completed

TL;DR: Please migrate your PR to flutter/flutter

The flutter/engine repository has been migrated to the flutter/flutter repository. This PR will no longer be landed here and must be migrated. To migrate your PR to the flutter repository, please follow these steps:

1. Create a patch for this PR:

   • Generate a patch set that represents the changes in this PR. The exact method will vary depending on your PR's history. If your PR includes merges, it is highly recommended that you rebase it onto main first.

   git format-patch $START_COMMIT..$END_COMMIT --stdout > combined_patch.patch

2. Update the patch for the new engine location:

   • The engine source code now resides in the engine/ subdirectory within the flutter/flutter repository. You'll need to update the file paths in your patch accordingly.

   # Insert the `engine/` prefix to all paths. Note that this usage works on macOS and
   # linux versions of sed.
   sed -i.bak \
   -e 's|^\(diff --git a/\)\(.*\) b/\(.*\)|\1engine/\2 b/engine/src/flutter/\3|' \
   -e 's|^\(--- a/\)\(.*\)|\1engine/src/flutter/\2|' \
   -e 's|^\(\+\+\+ b/\)\(.*\)|\1engine/src/flutter/\2|' \
   combined_patch.patch

3. Checkout and set up your Flutter development environment:

   • Follow the instructions in Setting up the Framework development environment to check out the flutter/flutter repository.
   • Remember to rename the origin remote to upstream (e.g., git remote rename origin upstream).

4. Set up the engine development environment within the monorepo:

   • Follow the updated instructions in Setting up the engine environment, paying close attention to the changes in gclient setup and location.

5. Apply the patch to a new branch:

   • Create a new branch in your flutter/flutter repository.
   • Apply the updated patch to this branch:

   git apply combined_patch.patch

6. Open a new PR:

   • Open a new PR in the flutter/flutter repository with your changes.
   • Reference this original PR in the new PR's description using flutter/engine#<PR_NUMBER>.

---

This is a canned message