JSpecify migration — Phase 3: datatypes and plugin-api (public API surface)

[jflo]

Parent: #10440

Scope

These two modules form Besu's public API surface for plugin authors. Treat them carefully — annotation choices ship as contract changes.

• datatypes (35 files) — also clean up the JSR305 straggler org.hyperledger.besu.datatypes.parameters.UnsignedLongParameter that still imports javax.annotation (left over from Migrate JSR305 nullness annotations to JSpecify #9995).
• plugin-api (112 files)

Why this is a separate phase

• Adding @Nullable to a return type is a documentation change, but adding @NonNull/removing nullability from a parameter tightens the contract for external plugin authors.
• These modules are good candidates for package-level @NullMarked rather than per-symbol @Nullable, because absence of @Nullable then documents the non-null contract for external consumers.
• Coordinate with plugin SPI maintainers before merging — downstream plugins may need to track changes.

Approach

1. Apply the build-file recipe from the parent issue.
2. Decide per package whether to @NullMarked the package (preferred for new public API) or annotate per-symbol.
3. For each public API change, note in the PR description whether the change is clarification (annotation matches existing behavior) or tightening (callers must update).
4. Add a CHANGELOG entry under "API" if any public method's nullability documentation changes.

Definition of done

• Both modules' build.gradle carries the NullAway block.
• ./gradlew :datatypes:compileJava :plugin-api:compileJava passes.
• UnsignedLongParameter no longer imports javax.annotation.
• CI green on a full build.
• Plugin SPI maintainers signed off.