wrap exceptions from callbacks in QuicError.CallbackError

[wfurt]

contributes to #75115.
It uses newly approved QuicError.CallbackError to make it clear what is coming from outside of core Quic.
I was originally thinking about inner try/catch but I decided too keep simple state variable to track if exception needs to be wrapped to keep it simple.

I also added test for scenario described in #75115 e.g. ODE leaking up but not stopping listener.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

contributes to #75115.
It uses newly approved QuicError.CallbackError to make it clear what is coming from outside of core Quic.
I was originally thinking about inner try/catch but I decided too keep simple state variable to track if exception needs to be wrapped to keep it simple.

I also added test for scenario described in #75115 e.g. ODE leaking up but not stopping listener.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Quic
Milestone:	8.0.0

[ManickaP]

Is there a downside of wrapping the callback calls with extra try-catch block? Or why did you chose to introduce the extra boolean?

[wfurt]

Is there a downside of wrapping the callback calls with extra try-catch block? Or why did you chose to introduce the extra boolean?

I generally consider trow catch expensive operation. But I don't have any numbers for this particular case. And personally I'm not fan of too much of nesting.

[ManickaP]

LGTM modulo comments, thanks.

[wfurt]

counter test failure looks unrelated.