feat: make RequestBuilder configurable

[WqyJh]

RequestBuilder is an interface, therefore, it's designed to be extensible.

type RequestBuilder interface {
	Build(ctx context.Context, method, url string, body any, header http.Header) (*http.Request, error)
}

However, currently it's a private field of Client, which make it impossible to customize.

type Client struct {
	config ClientConfig

	requestBuilder    utils.RequestBuilder
	createFormBuilder func(io.Writer) utils.FormBuilder
}

This PR moves requestBuilder to ClientConfig, making it configurable, so that users can implement their own RequestBuilder, which is very useful in situation of adding custom request headers and injecting tracing attributes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.67%. Comparing base (774fc9d) to head (4b70b10).
Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #725      +/-   ##
==========================================
+ Coverage   98.46%   98.67%   +0.21%     
==========================================
  Files          24       24              
  Lines        1364     1135     -229     
==========================================
- Hits         1343     1120     -223     
+ Misses         15        9       -6     
  Partials        6        6              

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

[sashabaranov]

@WqyJh thank you for the PR! Could you outline some cases where exposed HTTPClient is not enough?

[WqyJh]

HTTPClient is not enough for setting custom headers, which needs to modify *http.Request.

Custom headers is useful if you use an non-official api-key. What's more, it's also useful to pass tracing information through headers.

[sashabaranov]

@WqyJh it is possible to modify requests with custom Transport in http.Client. We have a basic proxy example in our README, and here's an example for telemetry (+ entire transport implementation)

On another note, I think the biggest problem with custom request builders is that users would need to substitute full request builder logic every time:

go-openai/internal/request_builder.go

Lines 31 to 50 in c84ab5f

	var bodyReader io.Reader
	if body != nil {
	if v, ok := body.(io.Reader); ok {
	bodyReader = v
	} else {
	var reqBytes []byte
	reqBytes, err = b.marshaller.Marshal(body)
	if err != nil {
	return
	}
	bodyReader = bytes.NewBuffer(reqBytes)
	}
	}
	req, err = http.NewRequestWithContext(ctx, method, url, bodyReader)
	if err != nil {
	return
	}
	if header != nil {
	req.Header = header
	}

It might make sense to introduce instrumentation just before request is sent similar to gRPC interceptors concept. That might have better ergonomics than implementing custom HTTP transport.