Refactor RequestData

[Mpdreamz]

This PR is meant as the first step to undo making RequestData the God Object it is today.

• RequestData is now completely readonly
• PostData is moved outside RequestData
• HttpMethod and Path and RequestParameters now live outside RequestData, more info on this later.
• OpenTelemetryData now lives outside RequestData.
• Fixes several instances of boxing in HeaderList constructors.

This now also introduces 2 new records.

EndpointPath a readonly record struct that instructs what API we're calling.
Endpoint takes and EndpointPath and Node to take ownership of Uri creations.

This is hopefully a first step where we can cache these in calling libraries.

• TransportConfiguration now implementents IRequestConfigation

The goal here is for RequestData to turn into BoundConfiguration and instance we can cache per TransportConfiguration. Unless a local per request configuration is provided in which case we'll need to new a new instance which is rare.

[flobernd]

Without having looked at it yet:

Unless a local per request configuration is provided in which case we'll need to new a new instance which is rare

Maybe we can find a way to avoid the allocations. I need the UserAgent to be present in the IRequestConfiguration in order to override it in high level integrations that allow users to pass in a custom instance of the client. In these cases, we can't modify the user agent in the ITransportConfiguration without affecting the whole client instance.

This would cause the allocation to happen for every single request.

[Mpdreamz]

There are two pieces a global TransportConfiguration and a local per request RequestConfiguration.

The goal although not yet implemented is that if TransportConfiguration is provided (one exist per client) we never have to allocate more then 1 RequestData for all requests. This is 90% of the time the case.

Do you need to specify a different UserAgent per request/api?

[flobernd]

The goal although not yet implemented is that if TransportConfiguration is provided (one exist per client) we never have to allocate more then 1 RequestData for all requests. This is 90% of the time the case.

Sounds great 👍

Do you need to specify a different UserAgent per request/api?

That's not the case, no. But I still need a way to override the UserAgent for every single request. This is beacuse in some high level integrations like e.g. the Semantic Kernel connector, we allow the user to pass an already initialized ElasticsearchClient instance to the integration (this is a pattern that we can't easily change as it's essential in a lot of scenarios like e.g. in a dependency injection container).

This client instance is internally used to perform the requests. We want to use a custom UserAgent here for tracking purposes, but at the same time we do not want to modify the "global" TransportConfiguration, because that would mess with the UserAgent on all other places where the user uses the same client instance.

My idea was to add UserAgent to IRequestConfiguration for this purpose.

Your refactoring is a good improvement anyways for all other cases where we do not have to override on a per-request basis. Maybe we can be smart in some way to optimize the per-request-override case as well.

[stevejgordon]

That's not the case, no. But I still need a way to override the UserAgent for every single request. This is beacuse in some high level integrations like e.g. the Semantic Kernel connector, we allow the user to pass an already initialized ElasticsearchClient instance to the integration (this is a pattern that we can't easily change as it's essential in a lot of scenarios like e.g. in a dependency injection container).

Would it make sense to consider the client passed to Semantic Kernel dedicated to that use, i.e. create an instance with the configured UA etc. that is only used by Semantic Kernel. If the app also needs to use a client for other ES-related code, they could have a second instance of the client configured for that use case. Although there is some extra overhead, this might be the rare use case where having more than one client in an app is reasonable?

[flobernd]

LGTM from a first glance 🙂

[stevejgordon]

LGTM too. Thanks for starting off this improved direction!