fix: ignore empty string when setting endpoint

[jooola]

Since we cannot return an error, we should never accept an empty string as a valid endpoint.

The current behavior is difficult to debug, when we set the endpoint to an empty string, the client fails with the unsupported protocol scheme erorr.

This might be a bit magic, but between having a panic and ignore the input string, I prefer the latter.

This is a great candidate for a potential v3 of the client, were we can validate options.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.83%. Comparing base (0deb045) to head (70c0f36).
Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #609      +/-   ##
==========================================
+ Coverage   67.68%   67.83%   +0.14%     
==========================================
  Files          48       48              
  Lines        5010     5011       +1     
==========================================
+ Hits         3391     3399       +8     
+ Misses       1198     1193       -5     
+ Partials      421      419       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jooola]

I'll update the docs with the new behavior if we agree on it.

[apricote]

This might be a bit magic, but between having a panic and ignore the input string, I prefer the latter.

I am undecided on that. I think silently ignoring this configuration error is bad, as it might lead to a client talking to the wrong endpoint. On the other hand this is probably unused by nearly everyone outside of Hetzner Cloud, so it does not really matter much.

What do you think about a warning message to stderr in this case? This makes it at least discoverable that something unintended is happening.

[jooola]

I would wait for the v3 to find the best solution and not implement a short term solution. Maybe with the event recorder we could send such thing but it is not there yet.

Closing for now;