validate -serviceAddr on startup and cli handler

[eliteprox]

What does this pull request do? Explain your changes. (required)

This change aims to bring awareness to orchestrators that setting 0.0.0.0 or any other non-public IP as the -serviceAddr flag will cause issues with receiving and processing work. This will also help improve network quality.

Specific updates (required)

• Logs a warning on startup if -serviceAddr contains 0.0.0.0
• Returns a validation error in livepeer_cli option 13: Set orchestrator config

How did you test each of these updates (required)

• Tested orchestrator on chain with https://0.0.0.0:8935 as -serviceAddr, confirm warning shows on startup

W0828 19:31:05.124127  733748 starter.go:1204] **Warning -serviceAddr is a not a public address or hostname; this is not recommended for onchain networks**

• Tested setting orchestrator config with livepeer_cli, option 13, confirm validation error is returned:

Enter the public host:port of node (default: https://127.0.0.1:8935)> http://0.0.0.0:8935
Error applying configuration: service address must be a public IP address or hostname

Does this pull request close any open issues?

AI-586

Checklist:

• Read the contribution guide
• make runs successfully
• All tests in ./test.sh pass
• README and other documentation updated
• Pending changelog updated

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 57.35155%. Comparing base (384b703) to head (aab1482).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
cmd/livepeer/starter/starter.go	0.00000%	2 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##              master       #3156         +/-   ##
===================================================
+ Coverage   57.34261%   57.35155%   +0.00894%     
===================================================
  Files             92          92                 
  Lines          15805       15813          +8     
===================================================
+ Hits            9063        9069          +6     
- Misses          6137        6139          +2     
  Partials         605         605                 

Files with missing lines	Coverage Δ
common/util.go	59.35252% <100.00000%> (+0.29455%)	⬆️
server/handlers.go	55.79937% <100.00000%> (+0.18552%)	⬆️
cmd/livepeer/starter/starter.go	7.74443% <0.00000%> (-0.01503%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 384b703...aab1482. Read the comment docs.

Files with missing lines	Coverage Δ
common/util.go	59.35252% <100.00000%> (+0.29455%)	⬆️
server/handlers.go	55.79937% <100.00000%> (+0.18552%)	⬆️
cmd/livepeer/starter/starter.go	7.74443% <0.00000%> (-0.01503%)	⬇️

[leszko]

Added one minor comment, other than that LGTM

[leszko]

I'll wait for the CI build and if it's fine, then I'll merge

[Strykar]

@eliteprox @leszko Sorry I'm late to this, I'm traveling.
This and #3165 are sweet!

Why accept private IP ranges at all with onchain, allow them only for offchain instead?
That flag is never expected to work with a private IP, the networking is left up to the Orchestrator to manage right?

Warning the user to use a public IP immediately followed by an example of (default: https://127.0.0.1:8935) seems contradictory.

instead something like:

Enter your FQDN hostname:port of the node (example: https://my.orch.net:8935)> http://0.0.0.0:8935
Error service address configuration: in onchain network mode this must be a hostname that resolves to a public IP address.

Would've shipped a PR for the error messages, but wanted to know how you felt about using Go net to filter by private and public ranges depending on which -network was set?

[eliteprox]

@Strykar Good suggestion! I agree the log message should be improved. I'd also like to change this from a warning to an error,

The main concern I have heard is it still common for developers to test on-chain scenarios locally with arbitrum-one-mainnet network instead of a testnet, so for now we decided to go with a warning only