Fix SubscribeAsync silently failing when Dapr sidecar is unavailable

[GeorgeTsiokos]

Summary

Fixes #1663

PublishSubscribeReceiver.SubscribeAsync used to silently fail when the Dapr sidecar was unavailable: the initial gRPC call could throw, and three background continuations could fault, with all of those errors disappearing into unobserved task exceptions. This PR closes both halves of that hole and makes the receiver safely re-subscribable.

• Initial-subscribe failures throw: SubscribeAsync catches RpcException from the gRPC stream setup and throws a DaprException with topic / pubsub context, then resets hasInitialized so the caller can retry once the sidecar is back.
• Background-task faults are no longer silent: HandleTaskCompletion no longer throws (which would have faulted the unobserved inner Task returned by _ = ContinueWith(HandleTaskCompletion, ...) — the exact bug class this PR set out to fix). Instead it caches the first fault per subscribe cycle in pendingBackgroundFault; the next call to SubscribeAsync drains and rethrows it, so callers that don't configure an ErrorHandler still observe the error.
• Single sidecar outage produces exactly one report: a new hasFaulted flag (CAS) dedupes across the three sibling continuations (FetchDataFromSidecarAsync, ProcessAcknowledgementChannelMessagesAsync, ProcessTopicChannelMessagesAsync), which previously could each fire HandleTaskCompletion for the same logical failure.
• Stream reset is race-free and leak-free: new ResetStreamStateAsync runs under the same SemaphoreSlim as GetStreamAsync, nulls clientStream before resetting hasInitialized, and disposes the prior AsyncDuplexStreamingCall<,> to release the gRPC call. This closes the race where a concurrent SubscribeAsync could observe a reset hasInitialized while still seeing a stale stream reference.
• SubscriptionErrorHandler-thrown exceptions are surfaced: if a user-supplied error handler itself throws, the original DaprException and the handler exception are combined into an AggregateException and cached for the next SubscribeAsync instead of being silently swallowed by an empty catch.
• Cancellation is detected across all inner exceptions: the OperationCanceledException short-circuit now inspects every entry in task.Exception.InnerExceptions rather than only the first, so a fault wrapping both an OCE and a real RpcException still surfaces the real error rather than being suppressed as a clean cancel.
• ErrorHandler delegate is invoked safely: ErrorHandler?.Invoke() is guarded by try/catch, with the catch now routing through the cache-and-rethrow path described above instead of being a silent drop.
• Continuations use CancellationToken.None: ensures error-handling continuations always execute even after the caller's token is cancelled, so faults aren't lost to OnlyOnFaulted not running.
• Doc comments updated: XML docs on DaprSubscriptionOptions.ErrorHandler and SubscriptionErrorHandler now describe the cache-and-rethrow contract accurately (the prior comment claimed errors "surface as unobserved task exceptions", which was both inaccurate and the original bug).

Test plan

Original test plan (unchanged, still passing):

• HandleTaskCompletion invokes ErrorHandler with DaprException wrapping the original exception
• HandleTaskCompletion does not throw synchronously when no ErrorHandler is set (now: caches for next subscribe)
• HandleTaskCompletion does not propagate when ErrorHandler itself throws (now: caches combined fault)
• HandleTaskCompletion does not invoke ErrorHandler for successful tasks
• SubscribeAsync throws DaprException wrapping RpcException when sidecar unavailable
• SubscribeAsync allows retry after RpcException failure (hasInitialized reset)
• SubscribeAsync resets hasInitialized for non-RPC exceptions (e.g. ObjectDisposedException)
• Tests use xUnit v3 patterns (TestContext.Current.CancellationToken)

New end-to-end repro tests (drive the real SubscribeAsync → ContinueWith → HandleTaskCompletion chain via a mock IAsyncStreamReader.MoveNext that faults — not by awaiting HandleTaskCompletion directly):

• SubscribeAsync_WhenBackgroundFetchFaults_WithoutHandler_NextSubscribeRethrows — the no-handler cache-and-rethrow path
• SubscribeAsync_WhenBackgroundFetchFaults_InvokesErrorHandlerExactlyOnce — hasFaulted dedupe across the three continuations
• SubscribeAsync_AfterBackgroundFault_NextSubscribeRecreatesStream — reset + retry obtains a fresh stream end-to-end (verified via Mock.Verify(..., Times.Exactly(2)))
• SubscribeAsync_WhenBackgroundFetchCancelled_DoesNotCachePendingFault — cancellation short-circuit doesn't pollute the pending-fault slot
• SubscribeAsync_WhenErrorHandlerThrows_CachesCombinedFaultForNextSubscribe — handler-faulted path produces an AggregateException with both the original DaprException and the handler's exception
• Verified the new tests genuinely reproduce the bug: with the source fix temporarily reverted, 5 of 6 fail with the exact "background fault not cached" / synchronous-throw symptoms the fix addresses
• All 68 tests pass on net8.0, net9.0, and net10.0 across multiple back-to-back local runs

🤖 Generated with Claude Code

[WhitWaldo]

Do note that I just merged a PR to support xUnit v3 so your unit/integration tests may need a refresh.

[GeorgeTsiokos]

Out of scope for this PR:

1. ProcessTopicChannelMessagesAsync swallows OperationCanceledException from the message handler — timeout-triggered cancellations are silently converted to the default response action with no logging.
2. FetchDataFromSidecarAsync has a bare catch (Exception) (line 351) that silently swallows channel-write failures, which could mask backpressure or disposal races.
3. No ILogger anywhere in PublishSubscribeReceiver — all the silent catches above exist because there's no logger to report to. Adding an ILogger parameter would let these be logged instead of swallowed.
4. ContinueWith + TaskScheduler.Default — the continuation pattern is fragile; a failed error handler's exception becomes unobserved. Modern async/await with a top-level try/catch would be more robust.