events: prevent undefined as an event name

[cjihrig]

This commit prevents undefined as an event name in addListener(), removeListener(), and emit().

Refs: #20923

A few things to note:

• The motivation here is that undefined as an event name is almost certainly a mistake. I considered giving null the same treatment, but decided not to as a first draft.
• The validation message claims that the 'eventName' input must be a string or symbol. Our documentation calls the parameter 'eventName', even though the code doesn't. The docs also call for a string or symbol, which simply isn't true.
• I tried to make this a minimally breaking change. If we require the input to be strictly a string or symbol, it will probably break a lot of perfectly good code that uses things like numbers. This kind of breakage seems unnecessary.
• I'm currently validating the addition and removal of listeners, as well as emit(). I considered adding validation to the methods that retrieve listeners, but I'm not sure that's necessary since they are only querying state, not modifying it.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[addaleax]

Big 💙 for keeping this change in behaviour minimal. :)

[jdalton]

If according to the message:

The "eventName" argument must be one of type string or symbol.

Why not restrict to that first thing in the affected methods instead of keying in on undefined specifically (some back compat concern)?

[BridgeAR]

It would be good to also validate null and objects. Both of them will clearly not behave as expected.

[BridgeAR]

are there other possible paramNames? Otherwise I think it would be best to inline that string.

[mscdex]

I agree.

[mscdex]

removeAllListeners() needs to be modified as well in the right places.

[jdalton]

If the guard is to ensure the "eventName" argument must be one of type string or symbol then it should be applied to more than just undefined. Blocking just because there are a couple approvals and I think it needs a bit more work.

[addaleax]

@cjihrig I’m sorry you closed this. Would you mind if I picked it up again? I think this is strictly an improvement, so I’d like to see it make its way into Node and blocking it seems inappropriate to me.