BFD-4155: Refactor EFT service into Greenfield Terraform

[malessi]

JIRA Ticket:
BFD-4155

What Does This PR Do?

This PR refactors the legacy eft Terraservice into the new ops/services Greenfield OpenTofu hierarchy using the new patterns and style. It has been split into 02-eft and 03-eft-o11y (this Terraservice being the child module of the legacy eft Terraservice—now independent). Largely, the BFD EFT service itself is the same.

In more detail, this PR:

• Introduces 02-eft to the Greenfield Terraform adapted from the legacy eft Terraservice
  • Resources have been refactored and re-organized to follow more modern BFD OpenTofu patterns and code style
  • Unnecessary resources (CIDR Reservations, CloudTamer-specific Roles, etc.) have been removed
  • sftp-outbound-transfer Lambda is now invoked by an SQS Queue associated with the existing Dead Letter Queue such that it is possible to easily redrive failing events
  • All SNS Topics now have logging enabled via the new logging-sns-topic OpenTofu Module (see below)
  • Introduces a new pattern for exporting automatic Terraservice outputs via SSM, see outputs.tf
• Introduces 03-eft-o11y to the Greenfield Terraform adapted from the bfd_eft_outbound_o11y child module of the legacy eft Terraservice
  • Resources have been refactored and re-organized to follow more modern BFD OpenTofu patterns and code style
  • outbound-slack-notifier now uses uv
  • Consumes the new SSM outputs from eft (see inputs.tf) for values that were originally provided via variables
• Introduces a new "general" OpenTofu Module for creating SNS Topics that log to CloudWatch Logs: logging-sns-topic
  • Creates all the necessary IAM resources, Log Groups, and SNS Topic
  • Exports the aws_sns_topic via outputs
  • Follow-up work will expand its usage to platform Terraservices and more

This PR seems quite large, and that is unfortunately due to copying the existing legacy Terraservice instead of moving it as we need to keep it around for the Greenfield transition of BFD EFT. Most additions are actually lines unchanged from the original Terraservice.

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

• See above

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies

• Modifies any security controls

• Adds new transmission or storage of data

• Any other changes that could possibly affect security?

• I have considered the above security implications as it relates to this PR. (If one or more of the above apply, it cannot be merged without the ISSO or team security engineer's (@sb-benohe) approval.)

• I have created tests to sufficiently ensure the reliability of my code, if applicable. If this is a modification to an existing piece of code, I have audited the associated tests to ensure everything works as expected.

Validation

Have you fully verified and tested these changes? Is the acceptance criteria met? Please provide reproducible testing instructions, code snippets, or screenshots as applicable.

• tofu applying eft and eft-o11y to test Greenfield, verifying that:
  • Both applys are successful with no unexpected changes
• sftping into the Transfer Family SFTP Server via the NLB created by eft, verifying that:
  • I am able to SFTP into it successfully and run commands
  • I am able to put a file to the bfd-test-eft... Bucket
• Monitoring the sftp-outbound-transfer Lambda after uploading a file to dpc/out, verifying that:
  • It is invoked automatically
  • The Lambda attempts to upload the file, but is unable to due to CMS EFT's external firewall
  • The failing event is, eventually, put into the DLQ and it is possible to redrive the event from the AWS Console
  • The outbound-slack-notifier sends a Slack message indicating failure, as expected

[malessi]

I have left comments on all relevant files that are entirely additions to help guide reviews towards code that actually should be looked at.

If a file—that is marked as totally new—was left uncommented, that file can be safely ignored as it was copied directly from the legacy eft code or is just altogether unimportant. Anything marked as having changes should be reviewed like normal.

For some files I explicitly mark the lines that were changed with respect to the legacy Terraservice/code. Others have more substantial changes where enumerating each block and what it corresponds to in the legacy code would be too onerous, so I just commented that there were relevant changes and where to find the original code.