refactor(crashlytics): migrate to nnbd

[russellwheatley]

Description

Crashlytics NNBD (null-safety migration).

Related Issues

Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[rrousselGit]

Looking good!

[rrousselGit]

If you're motivated, these could all be refactored to use expect(() => ..., throwsUnimplementedError)

And if you want to go fancy, we can also do:

expect(
  () => ...,
  throwsA(
    isA<UnimplementedErorr>()
      .having((e) => e.message, 'message', 'setCrashlyticsCollectionEnabled() is not implemented')
  ),
)

[Salakar]

+1 for this - can we do it on a separate PR though after this has been merged? 🤓

[russellwheatley]

I'll also add this to the backlog.

[russellwheatley]

Tracking here INVERTASE/FF-20

[Salakar]

LGTM

Edit; just noticed CI is failing now 😅 re-ran to double check

[russellwheatley]

@Salakar Yep, tests were failing because of this test.

It doesn't actually throw an error so the change @rrousselGit suggested, uncovered the first potential bug (needs investigation, the fact that android doesn't throw an error suggests it might not be expected) The second potential bug is the fail() function here. This doesn't fail the test as expected. I'll add a ticket to the internal backlog. I've commented it out for now so we can get this over the line.

Tracking here: INVERTASE/FF-19