fix: Use an AbortSignal for per-request timeouts

[JoshMock]

A potential fix for #63, largely inspired by a community member's PR that was never merged: #55

According to an Undici core committer in this comment the issue that triggers the MaxListenersExceededWarning, and possibly a memory leak in some cases, is caused by attaching an EventEmitter to each request by default when a per-request timeout is set, rather than attaching an AbortSignal.

My assumption is that an EventEmitter was used because AbortSignal and AbortController were not added to Node.js until v14.17.0, so we couldn't guarantee v14 users would have it. I'm not certain why using EventEmitters makes a difference memory-wise, but it does get rid of the MaxListenersExceededWarning.

[JoshMock]

@ronag Since you were helpful in digging into this issue with your knowledge of Undici, I'd love a quick review from you if you have the time. 🙏

[ronag]

LGTM but I'm unsure why you don't just pass null if there is no signal?

[JoshMock]

I'm unsure why you don't just pass null if there is no signal?

Because the code implements per-request timeout functionality, so it needs a signal to manually abort the request when the timeout is reached. @delvedor discussed adding this to the Undici library nodejs/undici#165 but the functionality never shipped, so he added similar logic to do the same thing here.

elastic-transport-js/src/connection/UndiciConnection.ts

Lines 130 to 142 in b006b9a

	// undici does not support per-request timeouts,
	// to address this issue, we default to the constructor
	// timeout (which is handled by undici) and create a local
	// setTimeout callback if the request-specific timeout
	// is different from the constructor timeout.
	let timedout = false
	let timeoutId
	if (options.timeout != null && options.timeout !== this.timeout) {
	timeoutId = setTimeout(() => {
	timedout = true
	requestParams.signal.dispatchEvent(new Event('abort'))
	}, options.timeout)
	}

[alexey-sh]

Does it breaks code which uses emitter(which is removed)?

[JoshMock]

Does it breaks code which uses emitter(which is removed)?

The use of EventEmitter is an internal implementation detail, not something exposed to end users, so removing it does not break the public contract.