Add Temporary AAR Exception CRUD support to the TROLIE Java client SDK

[naveenmullapudi260006549]

Add support for the TROLIE Temporary AAR Exceptions resource to the Java TROLIE Client SDK.

The TROLIE specification defines Temporary AAR Exceptions as a standard REST resource at:

• POST /temporary-aar-exceptions
• GET /temporary-aar-exceptions
• GET /temporary-aar-exceptions/{id}
• PUT /temporary-aar-exceptions/{id}
• DELETE /temporary-aar-exceptions/{id}

This SDK support is required so LEP can share Temporary AAR Exception lifecycle changes between peered TROLIE systems.

Scope

Add SDK model classes representing the Temporary AAR Exception resource, following the existing SDK package, naming, serialization, and client implementation conventions.

The model must support the fields defined by the TROLIE specification, including:

• id
• source
• resource
• start-time
• end-time
• continuous-operating-limit
• emergency-operating-limits
• reason

The existing shared model classes should be reused where applicable, including:

• DataProvenance for the source field
• PowerSystemResource for the resource field
• Existing rating and emergency-duration models where applicable

The source field must support the TROLIE data-provenance structure:

• provider
• origin-id
• last-updated

Client API

Add methods to TrolieClient and implement them in TrolieClientImpl for:

• Creating a Temporary AAR Exception
• Listing Temporary AAR Exceptions
• Getting a Temporary AAR Exception by ID
• Updating a Temporary AAR Exception by ID
• Deleting a Temporary AAR Exception by ID

The methods should use the existing SDK HTTP, authentication, error handling, media type, and request execution patterns.

Important lifecycle behavior

TROLIE does not define a separate terminate operation for Temporary AAR Exceptions.

Termination is represented as an update to the existing resource, normally by sending a PUT request with the updated end-time.

Therefore, no separate terminateTemporaryAARException SDK operation is required. The existing update operation must support this use case.

Serialization requirements

The SDK must serialize and deserialize the JSON property names defined by the TROLIE specification, including hyphenated names such as:

• start-time
• end-time
• continuous-operating-limit
• emergency-operating-limits
• origin-id
• last-updated

The implementation should preserve optional fields and correctly handle nullable values such as an open-ended end-time, where supported by the specification.

Acceptance criteria

• Temporary AAR Exception model classes are added to the SDK.
• source is represented using the existing DataProvenance model.
• resource is represented using the existing PowerSystemResource model.
• Create support is added for POST /temporary-aar-exceptions.
• List support is added for GET /temporary-aar-exceptions.
• Get-by-ID support is added for GET /temporary-aar-exceptions/{id}.
• Update support is added for PUT /temporary-aar-exceptions/{id}.
• Delete support is added for DELETE /temporary-aar-exceptions/{id}.
• Termination is supported through the update operation by changing end-time.
• Existing SDK authentication, HTTP error handling, and retry/client conventions are reused.
• JSON serialization/deserialization tests are added.
• Client request tests are added for all supported operations.
• Existing SDK tests continue to pass.
• The changes are compatible with the published TROLIE OpenAPI specification.