ref(docker): combine test and prod entrypoints into one

[gustavovalverde]

Motivation

Maintaining both entrypoint is not necessary, and having a single one help with refactors like:

• ref(workflows): consolidate workflows based on their purpose #7616

Fixes: #7639

Complex Code or Requirements

• A whole file disappears and it's merged into another
• Some extra changes were added to make the whole file less verbose and fix linting issues

Solution

• Uses -x instead of echoing the variables values
• Sets default values where required
• Create a function to list directories
• Create a function to run cargo tests
• Use a better approach to handle different options in the case manegement for tests and production
• Replaces all instances of runtime-entrypoint.sh with entrypoint.sh

Review

• Verify all tests are passing in this PR
• A long lived instance must be deployed from this PR to validate CD configuration

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?

Follow Up Work

Use arguments instead of variables, to run tests, based on the following comment:

• devops: Align tests names in CI, Docker and Rust code #7541 (comment)

[teor2345]

It might help to run a full sync with these script changes, to check that it works. But that's also a very slow test. What do you think?

I don't mind either way, as long as the full sync is working on main, we can wait for the end of the week. (But if it's not working on main that's a blocker.)

[gustavovalverde]

It might help to run a full sync with these script changes, to check that it works. But that's also a very slow test. What do you think?

If other tests are passing, it should be the same behavior with the full sync. If my any means this causes an odd behavior (which I wouldn't expect) it should be quick to fix or revert.

[teor2345]

It might help to run a full sync with these script changes, to check that it works. But that's also a very slow test. What do you think?

If other tests are passing, it should be the same behavior with the full sync. If my any means this causes an odd behavior (which I wouldn't expect) it should be quick to fix or revert.

Ok, but the full sync hasn't passed since 1 September, before the self-hosted runners changes. So did you want to wait for a successful full sync on main before merging these changes?

I am concerned we might end up with a stack of changes which might all contribute to the ongoing failures, and it's difficult to work out which ones are causing it. (Like we have in ticket #7618 in the Zebra Rust code right now!)

[gustavovalverde]

So did you want to wait for a successful full sync on main before merging these changes?

Oh yeah, that's ok, this doesn't has to merged beforehand as we'll all be focusing on fixing the full sync test.

In another note, the long-live instance is working.

Here's the workflow run: https://github.com/ZcashFoundation/zebra/actions/runs/6386506331

And the instance logs.

"A long lived instance must be deployed from this PR to validate CD configuration", but otherwise this PR looks great.