Fix CS8632 warnings in Service.Tests

[aaronburtle]

Why make this change?

Closes #3543

What is this change?

Changed one line in src/Service.Tests/Azure.DataApiBuilder.Service.Tests.csproj:

- <Nullable>disable</Nullable>
+ <Nullable>annotations</Nullable>

and we include a comment explaining the choice and linking back to issue #3543.

Why this particular approach?

Azure.DataApiBuilder.Service.Tests.csproj declared <Nullable>disable</Nullable>, but ~25 files in the project override it with a per-file #nullable enable directive. The issue arises when files used string? syntax without the per-file override, producing CS8632 noise in build logs and a latent risk of hard build breaks if TreatWarningsAsErrors=True ever propagated into the project.

Options considered

#	Approach	Why rejected (or chosen)
A	Strip ? from every offending file	High churn across many test files, easy to regress, and loses real intent (those ?s were added deliberately by file authors who used #nullable enable). Doesn't actually fix the underlying mismatch, a new file added tomorrow could re-introduce the warning.
B	<Nullable>enable</Nullable> to match the rest of the repo (Directory.Build.props sets enable)	Turns on flow-analysis warnings (CS8600 / CS8602 / CS8618 / CS8625, etc.) across thousands of lines of legacy test code that was written under disable. Because Directory.Build.props sets TreatWarningsAsErrors=True, every one of those becomes a build break. The scope to clean up is enormous and out of scope for this cleanup issue.
C	<Nullable>annotations</Nullable>	Exactly the C# language mode designed for this scenario. Permits ? syntax in the annotations context everywhere (no more CS8632), without enabling flow-analysis warnings on the unaudited bulk of the test code. The 25 files that already have #nullable enable keep their stronger setting.

Why annotations is the right C# language mode here

The C# nullable-context feature has two independent dimensions: the annotations context (do ? and ! mean anything?) and the warnings context (do flow-analysis diagnostics fire?). The four <Nullable> MSBuild values map to combinations of those two:

Value	Annotations	Warnings
disable	off → ? triggers CS8632	off
warnings	off → ? triggers CS8632	on
annotations	on → ? is legal everywhere	off → no CS8600/CS8602/etc. noise
enable	on	on

annotations is the only mode that fixes the reported problem (CS8632) without creating a much larger one (flow-analysis warnings turned into errors across legacy code).

Per-file #nullable enable directives are unchanged

The 25 files that declare #nullable enable (e.g. AuthorizationResolverUnitTests.cs, DabCacheServiceIntegrationTests.cs, the Mcp/ and Embedding* test files, etc.) have been audited for full nullable correctness and keep their stronger setting. Leaving them alone:

• preserves their existing nullable flow analysis,
• makes them defensive rather than load-bearing, they no longer silently mask a project-level inconsistency,
• avoids churn unrelated to this issue.

How was this tested?

1. Baseline. Clean rebuild of Service.Tests with the change: 0 Warning(s), 0 Error(s).
2. Regression probe. Temporarily added private static string? __nullableRegressionProbe = null; to RequestParserUnitTests.cs — one of the files called out in the issue, which has no #nullable enable directive. Rebuilt:
   • CS8632 count: 0
   • The only complaints were CA1805 / CS0414 about the unused probe field itself, unrelated to nullability and confirming the project setting tolerates ? in files without the per-file directive.
3. Final clean rebuild after reverting the probe: 0 Warning(s), 0 Error(s).

[Copilot]

Pull request overview

Updates the Service.Tests project’s nullable configuration to eliminate CS8632 warnings caused by nullable annotation syntax (string?) being used while the project was in <Nullable>disable</Nullable> mode. This aligns the project with the repo’s warning-as-error posture without turning on broad nullable flow-analysis diagnostics across legacy test code.

Changes:

• Switch src/Service.Tests/Azure.DataApiBuilder.Service.Tests.csproj from <Nullable>disable</Nullable> to <Nullable>annotations</Nullable>.
• Add an explanatory comment documenting why annotations was chosen and referencing issue #3543.