Fix default error handling for subscribe(with:)

[heoblitz]

Closes #2730

Summary

subscribe(with:) always passed a weak error-forwarding closure to its underlying subscription, even when the caller omitted onError or onFailure. That closure prevented unhandled terminal errors from reaching Hooks.defaultErrorHandler.

This change forwards an error closure only when the caller provides one. Without an explicit callback, the existing subscription implementation receives nil and invokes Hooks.defaultErrorHandler.

The behavior is aligned across Observable, Single, Maybe, and Completable.

Root cause and impact

The object-based overload previously converted an optional error callback into a non-optional closure. When the callback was absent, the closure simply returned, but its presence still made the underlying subscription consider the error handled.

Explicit onError and onFailure callbacks retain their existing behavior, including their weak object capture. The only observable change is that an error without an explicit callback is now handled through the configured default hook, as with the corresponding non-object subscription overload.

The test that customizes global hook state now restores that state after it finishes.

Validation

• Added regression coverage for all four affected types.
• Verified that explicit error callbacks receive the original error and do not invoke the default hook.
• Verified that omitted error callbacks invoke Hooks.defaultErrorHandler.
• Ran ObservableSubscriptionTest, SingleTest, MaybeTest, and CompletableTest with the macOS AllTests-macOS scheme.
• Ran git diff --check.

[freak4pc]

Thanks for this — the core fix is right, and mapping the optional through so the underlying subscribe sees nil is exactly the correct approach. Coverage looks complete too: those four are the only onError?(object, / onFailure?(object, sites, and Infallible has no error path. Restoring the Hooks state in defer is a good catch as well.

One request before I merge: could you drop a8046832 ("Improve test stability") and rebase on main?

It rewrites the three race tests in PrimitiveSequence+ConcurrencyTests.swift, which is unrelated to the subscribe(with:) fix, and it collides with #2727 — that PR reworks the same three tests as part of fixing the underlying cancellation deadlock. #2727 is going in first.

Its version is also the stronger one: it sets expectedFulfillmentCount = iterations so a task that never finishes actually fails the test. The version here keeps if i == iterations - 1 { expectation.fulfill() }, which under concurrentPerform makes the subsequent wait trivially satisfied (the loop already blocks until every iteration returns), and it drops the iteration count from 10 000 to 1 000.

Everything else in the PR is good to go.

[heoblitz]

@freak4pc Got it — looks like this was already being handled in the other PR. As requested, I dropped the test commit and rebased on main. Thanks for the review!

[heoblitz]

The tests had been failing because of this, but the latest commit with the test changes passed:
https://github.com/ReactiveX/RxSwift/actions/runs/33767087039