Add null-safety enforcement to signals with ErrorProne/NullAway and JSpecify

[heruan]

This is a fork of #22659 that limits the scope of the ErrorProne plugin to the signals module, including all the JSpecify annotations needed for a clean build. Notes:

• NullAway assumes @NotNull for non-annotated fields/params
• some null-checks are required even if certain statements are implicitly null-safe, e.g. getting a value from a Map<X, @Nullable Y>, even if the logic never puts null in that context (but it might do in a different context, hence the @Nullable Y)
• tests are excluded from the enforcement

[github-actions]

Test Results

1 277 files  1 277 suites   1h 12m 37s ⏱️
8 770 tests 8 666 ✅ 65 💤  2 ❌ 37 🔥
9 182 runs  9 014 ✅ 74 💤 16 ❌ 78 🔥

For more details on these failures and errors, see this check.

Results for commit 2a36b2c.

[Legioth]

tests are excluded from the enforcement

Would it make sense to have enforcement also in the tests so that we can see that typical application code with enforcement enabled would behave as expected?

[heruan]

Would it make sense to have enforcement also in the tests so that we can see that typical application code with enforcement enabled would behave as expected?

It would, and I first started with that but in tests we tend to ignore nullability when we know the tests won't fail for that (e.g. with mocks); also, adding a lot of if (foo == null) in tests to make the compiler happy might reduce readability.

On the other hand, I think it would be an encouragement to start making our API less @Nullable so that we don't need null-checks everywhere.

[sonarqubecloud]

Quality Gate passed

Issues
24 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[heruan]

In 9d49f64 I've enforced nullability checks in tests, mainly by asserting nullable values not being null before using them with assertNotNull. This keeps good readability avoiding adding conditional blocks, but still breaks method chains when they're not null-safe. For example, if we declare an AtomicReference<Foo> we cannot reset it with ref.set(null) and if we declare as AtomicReference<@Nullable Foo> we cannot call ref.get().bar().