Extracted methods into:

• AddBodyToRequest
• AddQueryParameters
• AddMultiPart
• AddHeadersToRequest
• AddPropertiesToRequest

I haven't changed any logic, this commit is to make it easier to understand the scope of logic and to cut down on the massive function. I plan on removing the following collections in a subsequent pr 🤞

var queryParamsToAdd = new List<KeyValuePair<string, string?>>(); // either use `ValueStringBuilder` or `ValueListBuilder`
var headersToAdd = new Dictionary<string, string?>(restMethod.Headers); `ValueListBuilder` or add directly with a check
var propertiesToAdd = new Dictionary<string, object?>(); // iterate params later on and directly add to `HttpRequest` both property/option are internally dictionaries.

Codecov Report

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

Project coverage is 83.90%. Comparing base (6ebeda5) to head (6f388dd).
Report is 49 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1740      +/-   ##
==========================================
- Coverage   87.73%   83.90%   -3.84%     
==========================================
  Files          33       36       +3     
  Lines        2348     2441      +93     
  Branches      294      328      +34     
==========================================
- Hits         2060     2048      -12     
- Misses        208      309     +101     
- Partials       80       84       +4     

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

@TimothyMakkison next conflict 😊

Should be done 🤞

I've been looking at removing the header dictionary and realised that I have to support .Net framework 😄 I'm currently planning on creating an inlinearray and converting it into a ValueListBuilder<KeyValuePair<string, string?>> for headers. The only way this is possible in .Net framework would be the use of unsafe code.

Would this be a deal breaker? Otherwise I can use some preprocessors and treat ,NEt Framework as a special case.

Let's keep the Netframework as a special case, there's a lot of companies that won't move forward until the last second and adopt new technologies. So long as the functionality of all TFM's are equal with regards to the output then we can even keep a separated section for Netframework, but it's a no from me for unsafe calls.
I am happy to provide a highly performant Netstandard2.0 / net6.0+ Version and if possible include Net462 otherwise create patches to keep the API and output standard.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.