feat: allow using custom debug write functions

[jooola]

Allow to configure custom functions to write the request/response debug logs.

[jooola]

We might want to make this configurable, e.g. we have a difference between the terraform logs and our CLI.

Maybe using a logging library is easier?

[codecov]

Codecov Report

Attention: Patch coverage is 74.19355% with 8 lines in your changes missing coverage. Please review.

Project coverage is 71.50%. Comparing base (468234e) to head (99246d1).

Files	Patch %	Lines
hcloud/client.go	50.00%	4 Missing ⚠️
hcloud/client_handler.go	0.00%	1 Missing and 1 partial ⚠️
hcloud/client_handler_debug.go	90.47%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #506      +/-   ##
==========================================
+ Coverage   71.46%   71.50%   +0.04%     
==========================================
  Files          46       46              
  Lines        3935     3959      +24     
==========================================
+ Hits         2812     2831      +19     
- Misses        710      714       +4     
- Partials      413      414       +1     

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

[apricote]

I am wondering if this is the right abstraction or if we should instead use OpenTelemetry Logger or log/slog.Logger

[jooola]

I thought about using slog directly, but this gives us more flexibility. We might need to support different logging framework, or format the dump before printing it out, having those callbacks allows it.

If we use slog, we might have to use a dedicated slog Handler to be able to get each key=value of a record, and then be able to print it out. This feel overkill in comparison to the callbacks. Note that the callbacks does allow using slogs, but the other way around is less straight forward.

I think adding open telemetry is a different topic, which I prefer not to mix with our dead simple debug output.

This PR can be backported to v1, while the open telemetry one, maybe less so.

That said, if we prefer to be conservative and not add yet another API for us to maintain over the years, I totally understand it and will try to implement open telemetry right away.

[phm07]

Why not pass a map[string]any so we could support more fields in the future?

[jooola]

I'd prefer not have an untyped map to pass more data. If we need more flexibility in the argument list, I'd rather use a struct.

What additional data do you think we will want to pass in the future ?

[jooola]

We can also allow the user to hook its own handlers inside the chain, but I am afraid to give that much freedom to the users of the Client, as it will be way easier to mess with the request/response objects.