Use StreamedRequest with onSendProgress in adapter

[Vovcharaa]

Fix #1835

New Pull Request Checklist

• I have read the Documentation
• I have searched for a similar pull request in the project and found none
• I have updated this branch with the latest main branch to avoid conflicts (via merge from master or rebase)
• I have added the required tests to prove the fix/feature I'm adding
• I have updated the documentation (if necessary)
• I have run the tests without failures
• I have updated the CHANGELOG.md in the corresponding package

Additional context and info (if any)

[SpeedReach]

Hello are you still working on this issue? I could complete this if you're too busy.

[Vovcharaa]

Hello are you still working on this issue? I could complete this if you're too busy.

You can take the lead in finalizing this feature.
But it is not possible to finish it right now. Check this dart-lang/http#997.
StreamSink in cupertino_http is buffering data and I don't know how to prevent this behavior so this feature won't work as intended. This must be handled on the cupertino_http side.

[SpeedReach]

I just tested with a larger data (more than 1024 bytes) according to dart-lang/http#997 (comment)
and it works fine.

  final dio = Dio()..httpClientAdapter = NativeAdapter();
  String superLargeData = 'aaa';
  for(int i=0;i<1000;i++){
    superLargeData += 'wwwww';
  }
  final res = await dio.post(
      "url",
      data: superLargeData,
      onSendProgress: (a,b){
        print('$a $b');
      }
  );

output:

flutter: 1024 5003
flutter: 2048 5003
flutter: 3072 5003
flutter: 4096 5003
flutter: 5003 5003

[AlexV525]

@Vovcharaa Are you still on this?
@SpeedReach If you want to continue based on the current work, please merge previous commits into your new branch to keep everyone's contributions recorded. Thanks.

[SpeedReach]

The changes @Vovcharaa made already completes the issue, but he didn't test it with data larger than the buffer, so he thought it didn't work.
This branch can be merged directly I think.

[AlexV525]

I looked at the implementation again and found I did the same thing in the new adapter. This can be easily addressed once we switch to the new adapter #1976.