Fix NPE when EmittingSubscription is cancelled while emitting

[cthiebault]

Motivation and Context

Fixes #7351.

EmittingSubscription is annotated @ThreadSafe, but cancel() and doEmit() race on the plain, non-volatile
downstreamSubscriber field. cancel() nulls the field; doEmit() checks isCancelled at the top of its loop and
dereferences downstreamSubscriber several statements later, after supplier.get(). A cancel() landing in that
window makes the emitting thread throw a bare NullPointerException out of Subscription.request(long):

java.lang.NullPointerException: Cannot invoke "org.reactivestreams.Subscriber.onNext(Object)" because "this.downstreamSubscriber" is null
    at software.amazon.awssdk.core.internal.async.EmittingSubscription.doEmit(EmittingSubscription.java:112)
    at software.amazon.awssdk.core.internal.async.EmittingSubscription.emit(EmittingSubscription.java:87)
    at software.amazon.awssdk.core.internal.async.EmittingSubscription.request(EmittingSubscription.java:71)

The S3 parallel multipart download path drives exactly that interleaving, on every single-part object:
ParallelMultipartDownloaderSubscriber.onSubscribe calls subscription.request(maxInFlightParts) synchronously on the
calling thread, and isMultipartObject() calls subscription.cancel() from an SDK response thread as soon as part 1
comes back with partsCount == null. Whether the download survives is decided purely by whether the emitting thread
finished its iterations first. We hit it as an intermittent S3TransferManager.downloadFile failure that no caller can
classify, since the NPE arrives unwrapped.

request(long n) has the same hazard on its n <= 0 branch.

Modifications

• downstreamSubscriber is now volatile.
• doEmit() reads it into a local once per iteration and returns when it is null or the subscription is cancelled, then
  signals through that local, so a concurrent cancel() cannot null it between the check and the signal.
• The n <= 0 branch of request(long) gets the same read-into-local guard.

This can still deliver one onNext to a subscriber that cancelled during supplier.get(), which Reactive Streams rule
2.8 explicitly permits ("a Subscriber MUST be prepared to receive one or more onNext signals after having called
Subscription.cancel()"). The field is still nulled in cancel(), so the reference is released for GC as before.

Not changed here, but worth a look separately: FileAsyncResponseTransformerPublisher.subscriber is also a
non-volatile field nulled in onCancel(), and two of its dereferences are unguarded — the "Content length header is
missing" branch of IndividualFileTransformer.onResponse, and handleError. Same defect class, same feature. Happy to
add it to this PR if you would rather have it in one change.

Testing

New EmittingSubscriptionTest with two cases, both deterministic (latch-driven, no sleeps):

• request_cancelledWhileEmitting_doesNotThrow — holds the emitting thread inside supplier.get() while another thread
  cancels, i.e. the exact interleaving above. Asserts request(2) does not throw and that at most one onNext is
  delivered.
• request_negativeDemandAfterCancel_doesNotThrow — covers the n <= 0 branch after a cancel.

Both fail on unmodified master with the NPE above and pass with this change.

Local runs on JDK 17 (Temurin 17.0.18):

mvn install -pl core/sdk-core   # 1538 unit tests + 624 TCK tests green, checkstyle clean
mvn checkstyle:check -pl core/sdk-core   # 0 violations

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license