Ensure random relay selection with fixed ohttp-keys config

[benalleng]

Closes #1384

This fixes a bug whereby the relay selection was skipped if the config set a fixed value for the ohttp-keys.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 22781790124

Details

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 82.497%

---

Totals
Change from base Build 22741440695:	0.0%
Covered Lines:	10638
Relevant Lines:	12895

---

💛 - Coveralls

[bc1cindy]

tested ACK 6097008

all tests passing locally

the fix is minimal and reuses fetch_ohttp_keys randomization, that also preserves the e2e relay validation, even when keys are hardcoded in config

[spacebear21]

utACK 6097008, though this makes me wonder if there is any benefit at all of having ohttp_keys in the cli config? We could just return the ValidatedOhttpKeys from fetch_ohttp_keys for the same effect, making the if/else block irrelevant?

[spacebear21]

Also relevant is this open PR #1035 , which would bypass the "e2e health check" aspect of fetch_ohttp_keys that is introduced here. cc @zealsham

[bc1cindy]

Also relevant is this open PR #1035 , which would bypass the "e2e health check" aspect of fetch_ohttp_keys that is introduced here. cc @zealsham

also related with #1391

[benalleng]

this makes me wonder if there is any benefit at all of having ohttp_keys in the cli config? We could just return the ValidatedOhttpKeys from fetch_ohttp_keys for the same effect, making the if/else block irrelevant?

I guess I would like to have more consensus on #1385 before we rip out the ohttp-keys from the config all together. I am happy to move on that as I think it ultimately makes sense.