This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.

When running on Fuchsia, respect the argument values that Skia passes
into the Flutter implementation of the |SkEventTracer| interface.

Bug: https://github.com/flutter/flutter/issues/48864

This reverts commit 6c605f8a.

* Revert "Add flow test fixtures and tests (#13986)"

This reverts commit 620f5281.

* Revert "Dynamically determine whether to use offscreen surface based on need (#13976)"

This reverts commit a86ef946.

The converters are still in a separate target that must be included manually. This allows targets that depend on FML but not Dart runtime not have to depend on the runtime.

Adds a test that includes this target and tests image decompression from assets. There is also a test for the standalone DartConvertor in shell_unittests but not in fml_unittests be cause FML uni-tests cannot yet launch a VM. I will work on adding fixtures for those.

* Add fuchsia MessageLoopImpl; fix several tests

Add fml_tests target for the fml unit tests on Fuchsia

Fixes https://github.com/flutter/flutter/issues/42704.

The core underlying issue is that vector push_back could re-allocate and cause us to segfault. I have switched the backing queues to a map per @jason-simmons suggestion in flutter/flutter#38778.

I've also added a test to capture the aforementioned bug. I've run internal tests several times to validate that this is fixed.

General threading note for this class is that only the following operations take a write lock on the meta mutex:

1. Create
2. Dispose

The rest of the operations take read lock on the meta mutex and acquire finer grained locks for the duration of the operation. We can not grab read lock for the entire duration of NotifyObservers for example because observer can in-turn create other queues -- Which we should not block.

Additional changes:

1. Make as many methods as possible const. Unlocked methods are all const.
2. Migrate all the queue members to a struct, and have a map.
3. Get rid of the un-used Swap functionality.

After pre-roll we know if there have been any mutations made to the IOS embedded UIViews. If there are any mutations and the thread configuration is such chat the mutations will be committed on an illegal thread (GPU thread), we merge the threads and keep them merged until the lease expires. The lease is currently set to expire after 10 frames of no mutations. If there are any mutations in the interim we extend the lease.

TaskRunnerMerger will ultimately be responsible for enforcing the correct thread configurations.

This configuration will be inactive even after this change since still use the same thread when we create the iOS engine. That is slated to change in the coming PRs.

When |OS_FUCHSIA| is defined (even when |FUCHSIA_SDK| is defined as
well), use the Fuchsia SDK trace macros rather than the Dart timeline.

Reasons for doing this include:

Fuchsia's trace macros support categories.  This allows one to
distinguish between (e.g.) "flutter" and "skia" trace events for trace
recording and trace visualization.

Fuchsia has existing in tree benchmarks that depend on finding certain
events under category "flutter".

See the Fuchsia performance mailing list discussion for more context.

- Add the functionality to merge and unmerge MessageLoopTaskQueues

This introduces a notion of a "owning" and "subsumed" queue ids.
Owning queue will take care of the tasks submitted to both that and it's
subsumed queue.

- The tasks submitted still maintain the queue affinity
- Same for the task observers

- Also adds MergedQueuesRunner which grabs both the locks owner
  and subsumed queues in RAII fashion.

- Also use task queue id to verify if we are running
  in the same thread.

- This is to enable merging the backed message loop task
  queues to enable dynamic thread merging in IOS.

* Refactor to move Task Queue to its own class

- This is to help with sharing task queue among
  multiple message loops going forward.

- currently there is 1:1 mapping between task queue
  and message loop, we are still maintaining the semantics
  for this change.

* Add mutex include

* Most of the waking up changes minus test failures

* Refactor MessageLoopImpl to be Wakeable

- Makes testing easier by letting us putting a TestWakeable

- Also move the waking up logic to the task queue

* add tests

* Fix formatting and license

* Refactor to move Task Queue to its own class

- This is to help with sharing task queue among
  multiple message loops going forward.

- currently there is 1:1 mapping between task queue
  and message loop, we are still maintaining the semantics
  for this change.

* Add mutex include

* Add unit tests for task queue

* fix formatting

* license

* Refactor Delayed Tasks to their own class

* fix some comments

* Update BUILD.gn

* Allow specifying both Dart and non-Dart fixtures in engine unittests.

This fixes numerous issues in the way in which fixtures were managed
in the engine unit-tests.

* Instead of only being able to specify Dart fixtures, unit-tests may specify
  non-Dart fixtures as well. These are simply copied over to the fixtures
  directory known to the unit-test at runtime.
* An issue where numerous Dart files could be given to the kernel snapshotter
  has been addressed. It was anticipated that such a (legal) invocation to the
  kernel snapshotter would produce a snapshot with the contents of all the Dart
  files added to the root library. This is incorrect and the behavior in this
  case is undefined.
* Dart files referenced by the main Dart file are correctly tracked via a
  depfile.
* The snapshotter arguments have been cleaned up to get rid of unused
  arguments (`—strong`) and  the use of the VM product mode argument has been
  corrected to no longer depend on the Flutter product mode.

This is forward compatible with std::size and similar to how Chromium
removed use of the arraysize macro.

This does not actually import the runners into the engine. It only sets up the targets so they need no modifications are necessary when the migration is done. The engine has been verified to build in both buildroots.

When flutter/synchronization was first authored, we did not own fml (it was called fxl then). Now we do, so use a single spot for such utilities. The pipeline was meant to be a general purpose utility that was only ever used by the animator (it even has animator specific tracing), so move that to shell instead (where the animator resides).

The number of workers depends on what the platform deem appropriate for the system at runtime.

There is already fml/memory/thread_checker.h

We should not be exporting anything from FML anyway.

libtrace-provider has libtrace listed as a dependency when really it
does not have any such dependency. This lets trace clients use
libtrace-provider as a dependency when what they really mean is libtrace.

This errant dependency in trace-provider is being fixed, which
means we need to fix these clients.

* Revert "Revert "Guard the service protocol's global handlers list with a reader/writer lock (#6888) #6895" (#6899)"

This reverts commit b6e93759 and applies fix for tests on Windows.

* Reland guard the service protocol's global handlers list with a reader/writer lock.

* Remove blank line

Revert "Guard the service protocol's global handlers list with a reader/writer lock (#6888) #6895" (#6899)

The service protocol holds the lock while waiting for completion of service
RPC tasks.  These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.

Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible.  AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.

Revert "Guard the service protocol's global handlers list with a reader/writer lock (#6888)" (#6893)

This reverts commit 9352360c.

(shared_timed_mutex is unavailable in the iOS build)

The service protocol holds the lock while waiting for completion of service
RPC tasks.  These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.

Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible.  AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.