worker: populate BroadcastChannel MessageEvent source

[SudhansuBandha]

Populate the MessageEvent source property with the sender's worker thread ID for BroadcastChannel messages originating from worker threads.

Fixes: #59053

[jdmarshall]

In the MDN documentation, https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent/source

The source read-only property of the MessageEvent interface is a MessageEventSource (which can be a WindowProxy, MessagePort, or ServiceWorker object) representing the message emitter.

The threadId might be sufficient to work with the new API you folks were working on but I'm wondering if there's a technical limitation that makes diverging from the web api an absolute necessity? Ideally this would be the Worker Object, since one could immediately invoke postMessage() for any rendezvous coordination necessitated by the broadcast. With that in mind a MessagePort would also work if that's available, but I'm guessing that is not...

[jasnell]

This is a breaking change making this a semver-major. It will need doc updates as well. I think we should instead try to find a way of doing this so that it's not a breaking change

[SudhansuBandha]

Thanks for the review, @jasnell. I agree that changing MessageEvent.source makes this a semver-major change. Do you have any particular approach in mind for exposing the sender information while preserving the existing semantics of MessageEvent.source? I'd like to make sure I'm exploring all feasible directions that best align with Node's API design.

[jdmarshall]

@jasnell Source currently resolves to null. Why would this a breaking change when there is nobody in the forest to hear the tree fall?

[SudhansuBandha]

node/deps/undici/undici.js

Lines 14727 to 14737 in 8fec65d

	static createFastMessageEvent(type, init) {
	const messageEvent = new _MessageEvent(kConstruct, type, init);
	messageEvent.#eventInit = init;
	messageEvent.#eventInit.data ??= null;
	messageEvent.#eventInit.origin ??= "";
	messageEvent.#eventInit.lastEventId ??= "";
	messageEvent.#eventInit.source ??= null;
	messageEvent.#eventInit.ports ??= [];
	return messageEvent;
	}
	};

Will it be feasible to add a Node Specific extension on MessageEvent (ex.- event.sender). This would avoid a breaking change while still allowing Node to expose sender information through a separate property.
cc. @addaleax @mcollina @jasnell

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.23%. Comparing base (0032189) to head (e392e56).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main   #64334    +/-   ##
========================================
  Coverage   90.23%   90.23%            
========================================
  Files         741      741            
  Lines      241194   241355   +161     
  Branches    45432    45467    +35     
========================================
+ Hits       217640   217798   +158     
+ Misses      15129    15128     -1     
- Partials     8425     8429     +4     

Files with missing lines	Coverage Δ
lib/internal/worker/io.js	99.21% <100.00%> (+0.02%)	⬆️

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[SudhansuBandha]

I have created an extension of the Undici based MessageEvent on Node to provide sender as a new property that will represent threadId in these message events. I have updated docs for the same as well as requested by @jasnell
Hope that this won't be leading to any breaking changes.