ci: Changes to release-pipeline, adding additional automation for setting up nodes locally.

[gzukel]

Description

Updates:

1. Updated the docker build pipeline for MacOS runners to install and run docker for building the image.
2. Adjusted the docker-compose for mainnet full nodes to have example of how to use the built docker images.
3. Modified the release-pipeline to follow the new release process with a manually executed pipeline with the ability to skip tests if emergency and the addition of an approval step.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

I executed the docker build pipeline from my branch to make sure changes worked for MacOS: https://github.com/zeta-chain/node/actions/runs/7893088980

I executed docker-compose locally to ensure the full-node synced with state-sync from the already built docker image.

I tested the updated publish release pipeline. I tested the skip tests works and the approval step works.

• Tested CCTX in localnet
• Tested in development environment
• Go unit tests
• Go integration tests
• Tested via GitHub Actions

Checklist:

• [N/A] I have added unit tests that prove my fix feature works

[github-actions]

!!!WARNING!!!
nosec detected in the following files: .github/workflows/publish-release.yml

Be very careful about using #nosec in code. It can be a quick way to suppress security warnings and move forward with development, it should be employed with caution. Suppressing warnings with #nosec can hide potentially serious vulnerabilities. Only use #nosec when you're absolutely certain that the security issue is either a false positive or has been mitigated in another way.

Only suppress a single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203
Broad #nosec annotations should be avoided, as they can hide other vulnerabilities. The CI will block you from merging this PR until you remove #nosec annotations that do not target specific rules.

Pay extra attention to the way #nosec is being used in the files listed above.

[lumtis]

LGTM