fix Fibers.Interrupted to avoid lock contention in Throwable::getCause

[fwbrasil]

I noticed this while optimizing Requests. When a large number of fibers is interrupted, sttp obtains the cause of the Interrupted exception, which is synchronized in Throwable. In this case, the cause is always null since it's a cached exception.

"kyo-scheduler-worker-33" #101 [56067] daemon prio=5 os_prio=31 cpu=59.03ms elapsed=0.65s tid=0x00000001018d0400 nid=56067 waiting for monitor entry  [0x00000008834d2000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.lang.Throwable.getCause(java.base@21.0.2/Throwable.java:422)
	- waiting to lock <0x00000002814c7760> (a kyo.fibers$package$Fibers$Interrupted$)
	at sttp.client3.SttpClientExceptionExtensions.defaultExceptionToSttpClientException(SttpClientExceptionExtensions.scala:29)
	at sttp.client3.SttpClientExceptionExtensions.defaultExceptionToSttpClientException$(SttpClientExceptionExtensions.scala:9)
	at sttp.client3.SttpClientException$.defaultExceptionToSttpClientException(SttpClientException.scala:24)
	at sttp.client3.HttpClientAsyncBackend.adjustExceptions$$anonfun$1(HttpClientAsyncBackend.scala:152)
	at sttp.client3.HttpClientAsyncBackend$$Lambda/0x000000b0012ccdd0.apply(Unknown Source)
	at sttp.client3.SttpClientException$$anon$1.applyOrElse(SttpClientException.scala:35)
	at sttp.client3.SttpClientException$$anon$1.applyOrElse(SttpClientException.scala:34)
	at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:35)
	at kyo.IOs$$anon$5.apply(ios.scala:53)
	at kyo.internal.KyoSttpMonad$$anon$3.apply(KyoSttpMonad.scala:19)
	at kyo.requests$package$Requests$$anon$2.apply(requests.scala:35)
	at kyo.scheduler.IOTask.eval(IOTask.scala:46)
	at kyo.scheduler.IOTask.run(IOTask.scala:83)
	at kyo.scheduler.Worker.runTask(Worker.scala:134)
	at kyo.scheduler.Worker.run(Worker.scala:112)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.2/ThreadPoolExecutor.java:1144)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.2/ThreadPoolExecutor.java:642)
	at java.lang.Thread.runWith(java.base@21.0.2/Thread.java:1596)
	at java.lang.Thread.run(java.base@21.0.2/Thread.java:1583)

[hearnadam]

Surprising this is not the default behavior

[fwbrasil]

Yeah, it'd be nice if NoStrackTrace had an override for this method.