feat(release): create Docker hub binary with mining enabled on release

[arya2]

Motivation

We want to make it easy for miners to test Zebra's getblocktemplate RPC methods.

Closes #6200.

Solution

• Add a Dockerfile with:
  • getblocktemplate-rpcs feature enabled
  • Network=Testnet by default
  • An exposed RPC listener port
• Add a workflow for building and publishing images on 'release'

Review

Anyone can review.

Reviewer Checklist

• Will the PR name make sense to users?
  • Does it need extra CHANGELOG info? (new features, breaking changes, large changes)
• Are the PR labels correct?
• Does the code do what the ticket and PR says?
  • Does it change concurrent code, unsafe code, or consensus rules?
• How do you know it works? Does it have tests?

[teor2345]

I'm concerned that we are creating a duplicate Dockerfile, it will be much harder to maintain than the single test/production Dockerfile we have at the moment.

Can we make the mining RPCs depend on a Docker argument instead?

[teor2345]

This PR will need a rebase on the latest main to pick up some new CI jobs.

[gustavovalverde]

I wasn't able to see this PR previously, but I do agree we need to make this happen on our existing Dockerfile.

@arya2 let me know if you'd like some help with this changes.

Duplicate files have been resolved

[teor2345]

This looks good, but I think we need to test it by making a fake .test release. workflow_dispatch won't work on this workflow, so we'll need to do the test after merging to main.

Here's the kinds of things I want to check:

1. Is the test or production image the first image that users see?
2. If users are pulling down the latest image, do they always get the production image?
3. Is the test image clearly marked as experimental?

If it could be confusing, our other option is to:

1. Use a different project name like zfnd/zebra-experimental
2. Remove any images we've pushed to the zfnd/zebra DockerHub

[teor2345]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed

[teor2345]

This looks good, but I think we need to test it by making a fake .test release. workflow_dispatch won't work on this workflow, so we'll need to do the test after merging to main.

Here's the kinds of things I want to check:

1. Is the test or production image the first image that users see?

2. If users are pulling down the `latest` image, do they always get the production image?

3. Is the test image clearly marked as experimental?

If it could be confusing, our other option is to:

1. Use a different project name like `zfnd/zebra-experimental`

2. Remove any images we've pushed to the `zfnd/zebra` DockerHub

@mpguerra @arya2 when do you think we should do this testing? Is it ok to wait until the next release and just see what happens?