feat(postgrest): abort requests

[Vinzent03]

What kind of change does this PR introduce?

feature

What is the current behavior?

One cannot abort a started http request. Even by adding a .timeout to the feature only ignores the result of the future but does not cancel its execution.

What is the new behavior?

Starting with http v1.5.0` it is now possible to abort requests.

final abortCompleter = Completer<void>();
Timer(Duration(seconds: 5), () => abortCompleter.complete());
try {
  final response = await client
  .from('table')
  .select()
  .abortCompleter(abortCompleter);
} on RequestAbortedException catch (e) {
 print('Request was aborted: $e');
}

Supabase-js uses .abortSignal, but since the dart implementation uses futures/completer I switched to .abortCompleter. But I'm not entirely sure and open for discussion about choosing a different name.

related: #898
The issue covers the general feature to abort requests, so we can cover aborting the requests in functions in another pr.

[Vinzent03]

For now waiting for the Dart sdk bump across all packages.

[Vinzent03]

Now that we've already bumped the minimum versions in v2 this has not to wait for v3.

[spydon]

Lgtm, I'll make sure that we add an example in the docs for this.

[spydon]

LLM review:

Two things I'd like to sort out before merging:

1. API shape. The builder only ever reads abortCompleter.future, it never completes it. Taking a Completer forces callers to allocate one even when they already have a future. Accepting the trigger directly is strictly more flexible and matches how http's Abortable models it:

   final response = await client.from('table').select()
       .abortSignal(Future.delayed(Duration(seconds: 5)));

   On naming: you raised this yourself, and I'd lean towards abortSignal(Future<void> signal). It mirrors supabase-js's .abortSignal, and a Future is the natural Dart analog of an AbortSignal. If we change the name, let's update the sdk-compliance.yaml symbol to match.

2. The exception isn't reachable by consumers. RequestAbortedException comes from package:http and isn't re-exported by postgrest (or supabase), so the on RequestAbortedException catch in your example only compiles if the user adds http as a direct dependency. Could we re-export it from postgrest.dart, or wrap it in a postgrest-native exception?

A few minor things, none blocking:

• The empty if/else branches in the new send closure are a bit awkward. Setting request.body only for post/put/patch and validating unknown methods separately would read cleaner.
• Bumping the shared _buildClient retry delay to 500ms plus the mock's 200ms delay slows the whole retry suite noticeably. Could the delay be scoped to just the abort test?
• The basic_test abort test catches the exception and only prints it, relying on the elapsed-time bounds. An explicit throwsA(isA<RequestAbortedException>()) would fail louder if abort silently regressed.

Deferring functions/storage to a follow-up is fine by me.

More info:

The PR's Completer is one indirection above the http primitive. It only unwraps to .future internally anyway, so wrapping it adds nothing. Two supporting points from http's own docs:

• It explicitly blesses both patterns: Completer for event-driven abort, Future.delayed for timeouts. Accepting a Future supports both; accepting a Completer only covers the event case cleanly (a timeout caller would have to build a Completer + Timer instead of a one-liner Future.delayed).
• "This future must not complete with an error." — a contract worth mirroring in our doc comment.