BFD-2906: Automate Maven Release Process

[malessi]

JIRA Ticket:
BFD-2906

User Story or Bug Summary:

As a BFD engineer I want to be able to have an automated release process that uses the maven release plugin to push build artifacts to CodeArtifact and ECR.

---

What Does This PR Do?

NOTE: This PR is being merged into an intermediate branch as additional changes are required before this process is usable

This PR:

• Adds a new GitHub Actions workflow named Build Release that can be started manually (see workflow_dispatch).
  • This workflow executes the following steps:
    • First, this new workflow will execute the Maven Release plugin, which will:
      • Build all modules within the parent pom.xml
      • Upon successful build, update all pom.xmls to the version specified by the operator
      • Create a commit with these updated pom.xmls on the branch specified by the operator (master, in the typical case), and create a tag from this commit with the release version as the tag name
      • Update the pom.xmls again setting their versions to the development version specified by the operator (typically <releaseVersion + 1>-SNAPSHOT)
      • Create a commit with these SNAPSHOT pom.xmls on the branch specified (usually master)
      • The Docker images generated by Jib will then be uploaded to ECR
      • All artifacts generated by the Maven Release build will then be uploaded to CodeArtifact under the bfd-mgmt repository, versioned appropriately
    • Then, assuming a successful run of the Maven Release plugin, the workflow will then generate a new GitHub prerelease based upon the Git tag generated by the Maven Release plugin with all of the relevant data dictionary files uploaded as assets under the new Release
  • Note that all Git operations done by this Workflow use the bfd-release GitHub Application, which is configured to bypass branch protection rules on master
• Updates the bfd-data-* modules to be included as part of the parent pom.xml so that they are versioned and built similarly to all other modules

This PR has been validated by:

• Running the new Build Release workflow against a protected branch, verifying that the workflow runs successfully, all Git operations succeed (and protections are bypassed), all artifacts are uploaded to their respective repositories, and a corresponding GitHub Release is generated with the appropriate data dictionary files appended as assets
• terraform planning the changes to mgmt, verifying that the plan does not include any unexpected changes and that all changes are valid

No changes to our infrastructure have been made as of this PR. I will apply mgmt when this PR is merged.

What Should Reviewers Watch For?

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

• Verify all PR security questions and checklists have been completed and addressed.

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then you must supply a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence here: N/A

  • Does this PR add any new software dependencies?
    • Yes
    • No
  • Does this PR modify or invalidate any of our security controls?
    • Yes
    • No
  • Does this PR store or transmit data that was not stored or transmitted before?
    • Yes
    • No

• If the answer to any of the questions below is Yes, then please add @StewGoin as a reviewer, and note that this PR should not be merged unless/until he also approves it.

  • Do you think this PR requires additional review of its security implications for other reasons?
    • Yes
    • No

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following prerequisite changes have been fully deployed:

• Branch protection rules on master are converted to equivalent rules using Rulesets, with the bfd-release GitHub Application exempted from those rulesets

Submitter Checklist

I have gone through and verified that...:

• I have named this PR and branch so they are automatically linked to the (most) relevant Jira issue. Ie: BFD-123: Adds foo
• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• The data dictionary has been updated with any field mapping changes, if any were made.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. DC GEO, BB2, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.

[brandoncruz3]

Looks good and verified in GHA. 🚀

[StewGoin]

After discussion with @mjburling today (I will allow him to summarize in a comment, etc...) I'm ok with this moving forward within the context provided by that forthcoming comment.

[lsmitchell]

Is updating the documentation for our release process included in this story, or is it recorded somewhere?

[malessi]

Is updating the documentation for our release process included in this story, or is it recorded somewhere?

We could probably include that as part of the follow-up Story, BFD-2907. This Story is specifically for getting the Workflow created -- BFD-2907 is the part where we actually integrate this new Workflow into our release process.

[brianburton]

Excellent work!

[mjburling]

This section is going to need some additional attention, post #2065

[malessi]

I've updated this to include the new .xlsx Excel worksheet and to follow the updated naming conventions introduced in #2065. That should be enough, but let me know if I missed something.