Move middleware and other generic components from graph core to the http core library

[baywet]

Looking at the sdk-design features list, there are a number of component that exist today in the graph core library which belong to the kiota http core library.
Most of those components are the middlewares.
If they exist, move the following components:

• pipeline (if not provided by the native http client)
• redirect handler (Add redirect,retry and compression handlers to HttpClient library for dotnet #589)
• compression handler (Add redirect,retry and compression handlers to HttpClient library for dotnet #589)
• retry handler (Add redirect,retry and compression handlers to HttpClient library for dotnet #589)
• authorization handler(see comment)
• logging handler(implicitly closed by Setup final handler for default httpClient #599. Users can use guidance here)
• chaos handler (Add Chaos and Telemetry Handlers #609)
• (optional) telemetry handler (make it generic enough so the request changes can be specified by a callback) (Add Chaos and Telemetry Handlers #609)
• multi-part content Pending resolution of multipart/form-data request content type is not handled properly #220 more context at Adds support for setting multipart content in RequestInformation #615)
  AB#10325

[andrueastman]

Hey @baywet,

I'm not sure if we really want to add an authorization handler in the kiota http core library by default. This is because,

• The default HttpCore takes in a mandatory IAuthenticationProvider contructor parameter here which always authenticates the RequestInformation instance before it is sent out here(I believe this may cut across several languages)

• If we want the authorization handler to use an instance of IAuthenticationProvider for authentication I believe that things might get a little tricky. The current IAuthenticationProvider specification states that it should act on an instance of RequestInformation here while the pipeline structure expects an instance of HttpRequestMessage. Since we convert the RequestInformation instance to a HttpRequestMessage instance to pass the request to the pipeline, it might be counterproductive to convert the HttpRequestMessage instance back to an instance RequestInformation so the IAuthenticationProvider may do its job then convert it back to an instance of HttpRequestMessage so that it may be passed further along the pipeline. (I believe this may cut across several languages as well)

[baywet]

@andrueastman you are correct, this issue was written before we revamped the authentication provider interface. In general I don't think having the authentication middleware is a good idea: it ties the authentication concern with a specific implementation of "transport" (http, with a specific client), which goes against our separation of concerns principles. I think we can skip this one, thanks for putting together the PRs for the other ones, I'll look into it ASAP.

[andrueastman]

No worries. Thanks for clearing that up @baywet 😄

[andrueastman]

Closing this for now.
The description has been updated to cover work done. Further enhancements are covered in their own issues below

• RetryHandler MUST respect retry-after: <date> #596
• CompressionHandler enhancements #598