Internalise HTTP extensions (remove dependency on HTTPlease)

[tintoy]

As discussed in #165, copy a minimum subset of functionality (e.g. URI templates, and consistent request/response handling) into dotnet-kube-client (e.g. in the KubeClient assembly under the KubeClient.Http namespace) to maintain source-level compatiblity (although not binary compatibility).

Where possible, use existing .NET extensions

Initial targeting should be for net6.0, net7.0, net8.0, net9.0.

Some initial notes

Possible (partial) replacement (of implementation) for HTTPlease URI-template functionality:

• https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.urihelper?view=aspnetcore-6.0
• https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.extensions.querybuilder?view=aspnetcore-6.0

(note: these look impractical to consume, since the only way to get access to them would require a <FrameworkReference Include="Microsoft.AspNetCore.App" /> from the KubeClient project that uses them)

Alternative implementation (and one of the most popular) of URI templates:

https://github.com/tavis-software/Tavis.UriTemplates

[tintoy]

Have split the HTTP client functionality out into a separate package KubeClient.Http that is an implicit dependency of the main KubeClient package. This will allow the HTTP and serialisation support (where the majority of discovered vulnerabilities in dependencies seem to occur) to be updated separately from the main client, if necessary.

Later, we can look at trimming this implementation (once the dust has settled from any breaks in compatibility) but for now it's pretty close to ready for release. I'm hoping to publish the new version of KubeClient in the next week or 2.

@raman-m - would you be interested in trying out the new version before I publish anything (to see if it's likely to cause any problems for you)? If so, I can make pre-release packages available on the project's MyGet feed.

Otherwise, I don't mind trying to pull down the Ocelot repository and try the upgrade myself (if you don't mind answering any questions that come up while I try to get it going).

[raman-m]

would you be interested in trying out the new version before I publish anything (to see if it's likely to cause any problems for you)? If so, I can make pre-release packages available on the project's MyGet feed.

Yes, I would be willing to collaborate on testing in January, as I am currently focused on releasing the Ocelot .NET 9 version.

Otherwise, I don't mind trying to pull down the Ocelot repository and try the upgrade myself (if you don't mind answering any questions that come up while I try to get it going).

Sounds reasonable. Why not wait for Ocelot v24.0, which will open a window for us to test both libraries?
Anyway, you can use the actual code in the develop branch to clone, compile, and test. Currently, it is unclear to me what tests should be provided from the Ocelot side?

[tintoy]

Yes, I would be willing to collaborate on testing in January, as I am currently focused on releasing the Ocelot .NET 9 version.

Great - thanks!

Basically, as long as it turns out that I’ve maintained source-code compatibility (excluding minor namespace changes) and behavioural compatibility then I think we’re good to go. Most of my concerns around the changes are what the upgrade experience will be like for existing consumers (which I can use when adding a migration guide to the documentation). I can wait til v24.0, but will also try out the develop branch in the meanwhile. I’ll see what existing tests there are in there that relate to the area where KubeClient is being used; since we now have a TestKit for KubeClient there may be some options there too.

[tintoy]

BTW, I’m planning on switching from JSON.NET to System.Text.Json eventually; is this likely to cause problems for you?

[raman-m]

is this likely to cause problems for you?

It depends. But seems we have independent referencing; thus, no problems should occur.
But FYI there is open PR ThreeMammals/Ocelot#2125, so we plan to support both Newtonsoft.Json and System.Text.Json packages until Microsoft no longer supports the Microsoft.AspNetCore.Mvc.NewtonsoftJson package.