PDJB-NONE: Inject singleton S3Presigner to fix native memory leak

[Travis-Softwire]

Ticket number

PDJB-NONE

Goal of change

Stop AwsS3FileDownloader leaking native memory by reusing a single S3Presigner instead of constructing a new one per request.

Description of main change(s)

• AwsS3FileDownloader now injects the singleton S3Presigner auto-configured by spring-cloud-aws-starter-s3, instead of calling S3Presigner.create() on every getDownloadUrl call.
• Each presigner owns an underlying SDK HTTP client, connection pool, and direct ByteBuffers. Creating one per call (and never closing it) leaked off-heap memory until ECS killed the task for exceeding its container memory limit. Reusing a single thread-safe instance removes the leak and matches the pattern already used for S3Client / S3TransferManager in the other AwsS3* services.

Anything you'd like to highlight to the reviewer?

• The other AwsS3* services (AwsS3FileUploader, AwsS3SafeFileDeleter, AwsS3QuarantinedFileDeleter, AwsS3DequarantiningFileCopier) were checked and already inject singleton SDK clients - no change needed there.
• We should separately add JVM-level diagnostics (-XX:NativeMemoryTracking=summary, -XX:MaxDirectMemorySize, -XX:+HeapDumpOnOutOfMemoryError, a sensible -XX:MaxRAMPercentage) so the next native-memory incident is debuggable rather than just an ECS kill. Those flags live in the deployment infra repo, not here.

Checklist

• Unit tests for new logic (e.g. new service methods) have been added — N/A, no behaviour change beyond reusing the bean; AwsS3FileDownloader has no existing tests

[JasminConterioSW]

Sounds plausible 🤞

[samyou-softwire]

out of interest, what documents that injecting S3Presigner will inject a singleton? this something in the library docs?