UID2-7015: add unit tests for attestation-aws

[BehnamMozafari]

Summary

• Add JUnit 4.13.2 and Mockito 5.12.0 test dependencies to attestation-aws/pom.xml
• Add unit tests: NitroExceptionTest (10), NitroAttestationParamsTest (2), NitroAttestationRequestTest (1), NitroAttestationProviderTest (3) — 16 tests total
• Wrap System.loadLibrary("jnsm") in try-catch UnsatisfiedLinkError in NitroAttestation.java so mockStatic can instrument the class in test environments (no production behavior change)
• Remove skip_tests: true from build-and-test and build-and-publish workflows so CI runs mvn test on PR and publish

Test plan

• CI build-and-test workflow runs and reports 16 passing tests
• All four test classes present: NitroException, NitroAttestationParams, NitroAttestationRequest, NitroAttestationProvider
• NitroAttestation still loads correctly in production (library present)

Design decisions

Why the result > 0 branch in generateAttestationRequest is not directly unit-tested

That method's only collaborator is private static native generateAttestationRequestInternal, which has no implementation in a test JVM. Mockito cannot stub private methods, so the branch can't be driven without either (a) relaxing the native method to package-private purely for tests, or (b) pulling in PowerMock to mock a private/native call. Both were rejected:

• (a) is a production change made solely to enable a test.
• (b) is a heavy dependency with poor Java 21 support that diverges from the plain-Mockito style used in uid2-attestation-gcp / uid2-attestation-azure (which the ticket asks us to mirror).

The branch itself is trivial glue, and its parts are already covered: NitroException.fromErrorCode is exhaustively unit-tested (all error codes + unknown paths), and NitroAttestationProviderTest covers both the success-slice path and the error → AttestationException wrapping path. Verified empirically that there is no zero-production-change way to test it: a mockStatic custom-Answer attempt to intercept only the inner native call still hits UnsatisfiedLinkError, because Mockito does not route the internally-called private static through the mock.

Why System.loadLibrary("jnsm") is wrapped in try-catch

NitroAttestationProviderTest uses mockStatic(NitroAttestation.class), which forces the JVM to load and initialize the class. The static initializer's System.loadLibrary("jnsm") throws UnsatisfiedLinkError in any JVM without the native library (i.e. CI / local test). Without the catch, Mockito's static-mock setup fails (Internal class redefinition failed: invalid class) and the provider tests cannot run.

Catching UnsatisfiedLinkError is behaviorally inert in production: on a real Nitro enclave libjnsm.so is always present, so the class initializes identically to before. The only difference is in a library-absent environment, where the failure shifts from class-load time to first native-call time — generateAttestationRequestInternal still throws UnsatisfiedLinkError on first use. Verified empirically: reverting to the bare loadLibrary call fails exactly the two mockStatic-based provider tests (14/16 pass); with the catch all 16 pass.

Jira: UID2-7015