Implement wildcard listeners

[Mihailoff]

Why

#3334

Ability to listen on any event:

consumer.on('*', (eventName, eventData) => {
  console.log(`Received event: ${eventName}`, eventData);
});

I'm not very familiar with the code base, hopefully, this is the right direction.

[Copilot]

Pull Request Overview

This PR adds support for wildcard ('*') event listeners in QueueEvents and covers this new feature with tests.

• Introduces a wildcardListeners collection and updates emit, on, off, once, and close to handle '*' listeners.
• Adds tests in tests/test_events.ts to verify wildcard listener behavior for built-in and custom events.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
tests/test_events.ts	Added two tests to verify wildcard listener invocation and data.
src/classes/queue-events.ts	Implemented wildcard listeners support and corresponding overloads.

Comments suppressed due to low confidence (1)

src/classes/queue-events.ts:338

• [nitpick] Add a JSDoc comment above the wildcard on('*', ...) overload to explain how and when wildcard listeners are invoked, and their order relative to normal listeners.

    if (event === '*') {

[Copilot]

[nitpick] Consider using a Set for wildcardListeners instead of an Array to prevent duplicate listeners and simplify removal logic.

Suggested change

	private wildcardListeners: Array<(eventName: string, ...args: any[]) => void> = [];
	private wildcardListeners: Set<(eventName: string, ...args: any[]) => void> = new Set();

[manast]

why do we need to discriminate the * event here?

[Mihailoff]

You are right, I think it should be just

if (this.wildcardListeners.length > 0) { ... }

[Mihailoff]

@manast what do you think about such design in general?

I tend to think that it is not the best choice and instead it should be something like example below without magical *.

queueEvents.onAll(handler)

In my case I ended up with a direct Redis consumer group listener to get full control of it.