DCMAW-11614: use SQS adapter when writing audit events in token, credential and activeSession lambdas

[sandymay-dd]

Jira Ticket

DCMAW-11614

This updates the asyncToken, asyncCredential and asyncActiveSession handlers to use the SQS Adapter sendMessageToSqs() . A similar piece of work has recently been done for the asyncIssueBiometricCredential handler: #1027

#1028 which adds full TxMA event body assertions to our API tests was completed recently ahead of this refactor.

Part of the reason to migrate away from the eventService.ts is that the writeGenericEvent() function is used in a number of different lambdas and not every event sent by this function is 'Generic'. This service is mocked out in lambda unit tests and the lambda unit tests validated the parameters sent to the writeGenericEvent() function, rather than the shape of the data being sent to the SQS.

Description of changes

Review guidance

Review checklist

Functional Review

• Functionality: Does it meet the acceptance criteria on the ticket and work as expected?
• Requirements: Does the code meet functional and non-functional requirements including compliance with programme standards and security gates?

Security & Compliance

• Personally Identifiable Information: Is it possible for PII to be logged?
• Security Considerations: Are there any security implications that need to be addressed?

Quality Assurance

• Testing: Is the code well-tested with sufficient coverage to provide confidence in correctness?
• Edge Cases: Have edge cases been considered and handled appropriately?

Code Quality

• Readability: Is the code easy to understand for all team members, with clear naming and appropriate documentation?
• Maintainability: Is the code easy to change, reuse, and extend?
• Code Style: Does it follow our coding conventions and best practices?
• Code Quality: Is the code maintainable and following best practices? See Values, Principles & Practices

Observability & Operations

• Observability: Are there appropriate logs/metrics that would help debug and monitor the service?
• Performance: Are there any performance considerations or potential bottlenecks?
• Runbooks for Alarms: If an alarm has been created or updated, has a corresponding runbook been created or updated?
  • Critical alarms runbook
  • Warning alarms runbook

Documentation

• Documentation: Is the code well documented? Is there any existing documentation that needs updating?
• Comments: Are complex sections of code adequately commented if the intent is not clear?

Review PR:

• Title: Contains ticket number and clear summary of change
• Description: Has clear description of change

Evidence

Documentation

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud