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.

[DanGould]

What makes you feel like there's non-consensus on #1385? Do you mean specific voices? looks like thumbs up & this pr and #1399 are all acked. Where do you think the second guessing comes from?

[benalleng]

I think I meant that the discussion there in #1385 and this comment specifically raises the question as to whether we should abandon the session approach all together and go towards a per-request approach. I do think that this PR and #1399 can and should be merged to address the specific issue this addresses and move away from the health checks all together in a separate PR