Don't use dependent abort signals inside Subscriber

[domfarolino]

Before this pull request, a Subscriber's internal signal — the one exposed by Subscriber#signal() — was a dependent signal based on two input signals:

1. The SubscribeOptions#signal, if non-null; and
2. The Subscriber's internal AbortController's (named complete or error controller before this CL) AbortSignal.

Then, whenever the internal dependent signal is aborted, we run the abort algorithm which (a) "closes" the subscription (sets subscriber.active to false), and (b) executes all teardowns.

But (1) the use of dependent AbortSignals (i.e., making each Subscriber's signal dependent on its downstream Subscriber's signal), and (2) tying a Subscriber's teardown execution to its internal signal's abort algorithms, introduced inconsistent teardown ordering for Observables chained together. Specifically, the order of teardown execution across Observables in a chain depended on whether the Observable chain experienced producer-initiated vs. consumer-initiated
unsubscription. Example:

const a = new Observable(subscriber => {
  window.sourceSubscriber = subscriber;
  subscriber.addTeardown(() => console.log('A teardown'));
});

const b = new Observable(subscriber => {
  subscriber.addTeardown(() => console.log('B teardown'));
  a.subscribe({complete: () => subscriber.complete()}, {signal: subscriber.signal});
})

const ac = new AbortController();
const signal = ac.signal;
b.subscribe({}, {signal});

// Prints `B teardown`, then `A teardown`
// ac.abort();

// Prints `A teardown`, then `B teardown`
// window.sourceSubscriber.complete();

Upstream teardowns (a) should run before downstream teardowns (b). The reason the consumer-initiated case is backwards is due to the ordering or abortion among dependent AbortSignals. Specifically, once we abort the developer passed-in AbortSignal, the first thing that runs are the abort algorithms, which runs local teardowns first. Then, DOM proceeds abort any dependent (aka upstream) signals, which then runs those upstream teardowns, before aborting even more upstream signals, and so on.

---

To fix this, this PR introduces two small but significant changes to the underlying AbortSignal infrastructure in Observables.

The first thing this PR does is stop making a Subscriber's internal signal a dependent signal based on the developer-supplied one (if one exists). The abort timing of dependent signals led to downstream Subscribers being aborted (teardowns and all) before upstream Subscribers (in the consumer-initiated unsubscription case, that is).

Instead, now the Subscriber maintains an internal AbortController (similar to today's "complete or error controller"), and its internal signal is that controller's signal. Then, like before, if a signal is provided in SubscribeOptions, we add an abort algorithm to it to close the subscription.

The second change this PR introduces is a change to the "close" algorithm itself. In addition to just setting active to false, it now aborts the Subscriber's internal controller. This kicks off the aborting of any upstream Subscribers right away, since those upstream "close" algorithms run (as an abort algorithm) in response to the downstream Subscriber's signal abort. This means "close" climbs all the way to the top-most upstream Subscriber/AbortSignal right away, before running any teardowns. Only after a subscription has been "closed", and after all upstream signals have been aborted, does the current Subscriber run its teardowns.

This changes the timing of things. In the consumer-initiated unsubscription case, instead of downstream signals running their teardowns and then "closing" their dependent (upstream) signals after, the first thing a downstream signal does in response to abort is "close" any upstream subscribers first.

Now imagine you have the following Observable chain:

a
  .operator() <-- (b) Observable
  .operator() <-- (c) Observable
  .subscribe({}, {signal});

Upon aborting signal you'd get the following flow:

1. Downstream signal aborted
  1. (C) "Close" algorithm runs
    1. (C) Aborts its internal controller
      1. (B) "Close" algorithm runs
        1. (B) Aborts its internal controller
          1. (A) "Close" algorithm runs
            1. (A) Aborts its internal controller
            2. (A) Teardowns run
        2. (B) Teardowns run
    2. (C) Teardowns run

Before this PR, the timing flow was like this:

1. Downstream signal aborted
  1. (C) Signal aborted
    1. (C) Close algorithm
      1. (C) Teardowns run
    2. (B) Signal aborted
      1. (B) Close algorithm
        1. (B) Teardowns run
      2. (A) Signal aborted
        1. (A) Close algorithm
          2. (A) Teardowns run

Tests are being written and landed in https://chromium-review.googlesource.com/c/chromium/src/+/5676226.

---

Preview | Diff

[domfarolino]

Ben has approved the tests, and the Chromium implementation updates for this have landed, so I'll merge the spec now.