* enable lint prefer_asserts_in_initializer_lists

* enable --assert-initializer

* round 3

* partially address comments

* merge

* review notes

* review

* review

* review

* Quiet debug test runner output when in machine mode.

See: https://github.com/flutter/flutter-intellij/issues/1176

* json => machine

- remove unused collector parameter
- clarify a comment
- inline _currentPackageTestDir

And add comments explaining why.

Currently this just prints the observatory URL as a JSON event.
Refactored the code to make this fit in.

Builds on engine fixes to #9813

Also fixes #7366

This reverts commit 9f5fa31e.

* add @required when there's an assert not null

* address review comments

* Bump to Dart SDK 1.23.0-dev.10

* allows us to understand flutter usage via telemetry
* brings in `@immutable`

Fixes: #9042

* completer fix

* Update to platform 1.1.1.

This assumes a fix to https://github.com/dart-lang/test/issues/542

The timeout added in this patch is a workaround for https://github.com/dart-lang/coverage/issues/165

Make debugging tests in a debugger easier.

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

...now that we have generic methods, their types need to be specified too.

This brings the feature back, since removing it broke one of our more
exotic sets of customers.

Also, defer to test package for throttling (this will require a test
package update as well).

Also, add a lot more instrumentation to --verbose mode for tests, and
fix minor trivial things here and there, and add error handling in
more places.

Also, refactor how coverage works to be simpler and not use statics.

When a machine is heavily loaded, it can severely delay the time it
takes for the OS to start a process once it's asked to do so. Our
5 second timeout that we were giving the test process to connect
to the test harness seemed like plenty of time, were it not for the
fact that the test process itself was not being started in time when
CPU throttling was in effect.

This change updates the test timeout to begin counting only once the
test process has been started. We keep the original timeout in play
in the event that the test process *never* starts up for some reason,
but we up that timeout value to 5 minutes.

Previously, it was possible for the test harness to bail
and the test runner to complete before the platform plugin
triggered the collection of coverage data. This fixes the
race condition such that the pending coverage collection
task is recorded immediately after starting the process.

We now produce a more reasonable error message when we're missing the
flutter_test dependency in a test. Also, remove the flutter_tools stack traces
when the engine dies.

Fixes #6187

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

When a test runs to completion, the test harness closes the stream side of the
StreamChannel, causing the sink side to be closed as well.  So by the time we
receive a test result of completed/harnessBailed, the controller sink has been
closed.

This ensures that accidental usages of dart:io's
file API don't creep in over time.

This removes direct file access from within flutter_tools
in favor of using `package:file` via a `FileSystem` that's
accessed via the `ApplicationContext`.

This lays the groundwork for us to be able to easily swap
out the underlying file system when running Flutter tools,
which will be used to provide a record/replay file system,
analogous to what we have for process invocations.

It is not enabled by default in the VM because applications not launched via the tools may try to connect with the debugger. This causes the debugger and the IDE to hang on Mac.

With this change, they're run via instance methods on an object
obtained through the context. This will allow us to substitute
that object in tests with replay/record versions to allow us to
mock out the os-layer in tests.