DefaultX509Source stops receiving SVID rotations after a rejected X.509 context update #486

Description

DefaultX509Source throws a WatcherException from its X.509 context watcher's onError. When the error comes from an update that GrpcConversionUtils.toX509Context rejects (for example a corrupted certificate or key, or a SPIFFE ID mismatch), StreamObservers calls watcher.onError from inside StreamObserver.onNext. The exception escapes onNext, gRPC cancels the call (CANCELLED: Failed to read message.), and since CANCELLED is non-retryable the watch ends permanently.

After that, the source keeps serving the SVID it already has and never applies another update. Once that SVID expires, every TLS connection built on the source fails, and only a restart recovers.

DefaultJwtSource and CachedJwtSource had the same problem with the JWT bundles watcher, fixed in #482. DefaultX509Source still has the old pattern:

Reproduction

A fake Workload API streams three X.509-SVID responses on one FetchX509SVID call: a valid one with hint initial, a corrupted one, then a valid one with hint rotated. DefaultX509Source.newSource(...).getX509Svid().getHint() returns initial. The third update is never delivered.

Expected behavior

As with the JWT sources: an error before the first update makes newSource fail. After initialization, a rejected update is logged, the current SVID and bundles are kept, the stream stays open, and the next valid update is applied.