Fix abort handling

[timursevimli]

• tests and linter show no problems (npm t)
• tests are added/updated for bug fixes and new features
• code is properly formatted (npm run fmt)
• description of changes is added in CHANGELOG.md
• update .d.ts typings

[axbuglak]

After this fix, default values will be used after all abort signals. So we should check if this is a signal from timer. I think it might look something like that. And we already have one test for timeout, so maybe it would be better to just add dc.signal.addEventListener('abort' to it?

[timursevimli]

After this fix, default values will be used after all abort signals. So we should check if this is a signal from timer. I think it might look something like that. And we already have one test for timeout, so maybe it would be better to just add dc.signal.addEventListener('abort' to it?

Thanks for the suggestions! Indeed, a timeout test already exists, but I missed it. I think we can follow your suggestion by adding dc.signal.addEventListener('abort', (reason) => { ... }) to the existing test instead of two almost identical tests with timeouts.

I'm not sure if we should handle the this.#default() method differently. What I mean is that if the error is caused by a timeout, call this method, and if the error occurs due to some other reason, then do not call it. I believe this is not correct behavior.

@tshemsedinov What do you think about it? Should the handling of the this.#default() method be different depending on the reasons for the error?