feat(dynamite_runtime): make DynamiteClient extend http.Client

[Leptopoda]

My plan is to adapt the request manager to work with a generic http.Client and a Request.
From there the request manager can use streams, converters and whatever it needs.
This would unify/deduplicate the RequestManager.wrapUri, RequestManager.wrapBinary and RequestManager.wrapNextcloud (leaving only the webdav methods separate for now).

By creating a custom request we are able to easily change the http method to a HEAD if we decide to use it for caching later on.

Please provide feedback on the dynamite_runtime changes (should we really have that many converters?
It also contains other corrections like respecting the content-type header that I can land in separate PRs if desired.

[provokateurin]

The code looks good, but the tests are failing and I'm really seeing the direction this is going. Can you roughly explain why the changes are needed or how this will be used later on?

[provokateurin]

First I've never seen this syntax 😅 and it also is not very readable to have it all in the if statement

[Leptopoda]

Dart3 pattern matching :P

Do you really think the usual if is easier to read?

    if (request is DynamiteRequest) {
      final validStatuses = request.validStatuses;
      if (validStatuses != null && !validStatuses.contains(response.statusCode)) {
        
      }
    }

or as we do not need the validStatuses itself

    if (request is DynamiteRequest && request.validStatuses != null 
      && !request.validStatuses!.contains(response.statusCode)) {

validStatuses is a getter so we do not get null check elevation.
I agree that it might not be strictly necessary here but I would also not be against it in general. It can help reduce a lot of boilerplate code.

[provokateurin]

Either of those options are better than the current one imo.

[Leptopoda]

but the tests are failing

I did not add the dynamite (generator) changes yet. Neither did I add the re generated nextcloud and petstore code.
I found it easier to understand (the dynamite changes themselves might need multiple PRs as there where bigger restructures involved).

Can you roughly explain why the changes are needed or how this will be used later on?

I think the first PR post sums it up nice.
The idea came when I tried to change the request handling and decoding of images. We currently require all of them to be DynamiteRawResponses which creates some overhead. My broader goal was to make the request manager work with any type of request and response unifying the special handling we currently have for wrapUrl and wrapBinary.
I attached a patch where I realised that the current way is too complex.

request_manager.patch.txt

[Leptopoda]

Should be pretty ready for the next round of feedback.
@provokateurin I'll need your help with the regex magic

I didn't migrate all request manager methods yet as the PR is already enormous.
Should I split it apart?

[provokateurin]

Please split everything you can, as long as it makes sense 😅 Then it can be reviewed and merged much faster.

[Leptopoda]

Closing in favor of the separate PRs