The current blocker on this is rolling http to the new version in the tests. I'm looking into how to fix fake_http.dart

There's 21 tests failures remaining that require non-trivial fixes.

• 6 have to do with the flaky issues using a generic function on a mock, which isn't supported (it was able to rely on a null value)
• 9 have to do with some weird mockito setup and not using a provided stub (github webhook)
• 6 have to do with previously null bigquery values in refresh chromebot status

There's 21 tests failures remaining that require non-trivial fixes.

• 6 have to do with the flaky issues using a generic function on a mock, which isn't supported (it was able to rely on a null value)
• 9 have to do with some weird mockito setup and not using a provided stub (github webhook)
• 6 have to do with previously null bigquery values in refresh chromebot status

Is this something that we can crowdsource? it is blocking already several changes to the backend.

That would be great as I need to head out for an appointment. Feel free to add commits to this PR for the fixes.

The remaining handlers can be crowdsourced:

1. get-status DONE
2. refresh-chromebot-status DONE
   3. github-webhook DONE
3. file-flaky-issue SKIPPED
4. Add mocks.mocks.dart to the license check DONE

Once these are done, we'll need to squash the PR into one commit, and rebase with tip of tree, fixing the issues there.

Then we can format and do a prod test.

There's one other issue, and I'm trying to find a solution:

when(mock.methodThatReturnsStream).thenAnswer((_) => Stream.empty());

Mockito will not return Stream.emtpy() in the tests, or store it as a stub. I asked in #hackers-test to get ideas, but from the documentation it sounds like this should work.

I'm working on the last issue regarding the mock generics. I was able to find https://github.com/dart-lang/mockito/blob/master/NULL_SAFETY_README.md#fallback-generators and i'm working to implement it now.

I'm disabling the flaky issue tests as they're non-critical and blocking this PR. flutter/flutter#90139

I'm going to squash these commits to rebase on top of master (\cc @keyonghan @godofredoc feel free to review now)

I wouldn't expect this to break main features, but can we validate the PR in a test version before merging?

Yes. My expectation is the review will take longer than the prod traffic test, so I wanted to get early eyes on it. I'm also debugging issues through the local dart server. I added a preview link to the PR description

Another AI is I need to revisit the model classes and mark everything as nullable, otherwise dart:mirrors doesn't work properly

The only issue i'm noticing is BuildBucketClient._postRequest is always failing with BuildBucketException: [400]: could not decode body: illegal base64 data at input byte 0.

I'm adding some logs to see what the message looks like, and see if there are any missing headers.

The only issue i'm noticing is BuildBucketClient._postRequest is always failing with BuildBucketException: [400]: could not decode body: illegal base64 data at input byte 0.

After some more debugging, it's not always failing. For some reason it can pass on the exact same call (like refresh-chromebot-status querying all the same builds, but then fail on push-build-status-to-github)

I did a prod traffic test with service/buildbucket.dart using the original dart:io calls, and that is still returning a malformed response. I suspect there is an issue in the model/buildbucket.dart migration

I'm submitting this, but there's a known issue where the waiting for tree to green graphql queries can timeout ~20% of the time. I filed to flutter/flutter#90640 to track