fix: uv loop polling when render process reuse enabled

[codebytere]

Description of Change

Closes #22119.
Closes #25314.
Closes #23910.
Closes #25405.
Closes #25496.

Fixes an issue where some Node.js module API calls hung in the renderer process on reload when renderer process reuse was in effect. This was happening because when render process reuse was enabled, Chromium reused the same process, but the main thread was still bound to the old iocp (on windows, and respective interface for other platforms) because libuv didn't destroy it. The queue then went on to operate on this old iocp - when we reloaded, a new iocp was created but not bound to the main thread and so we would not properly be informed of events on it. This is fixed by preparing the message loop on every reload when reuse is enabled with node_bindings_->PrepareMessageLoop().

cc @zcbenz @deepak1556

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue where some Node.js module API calls hung in the renderer process after reloads when render process reuse was enabled.

[zcbenz]

Busy looping is not a solution for listening to events. Apart from constant high CPU usage, when consuming streams it would add the delay for each chunk, making IO very slow.

[codebytere]

@zcbenz that does make sense and i don't think this is the ideal solution either - it's not clear to me what specifically is lacking in the previous approach though to make it hang in the way it was doing. Do you have any thoughts on an alternative?

[zcbenz]

I have not looked into the issue, but it seems that the issue is caused by GetQueuedCompletionStatus(uv_loop_->iocp) no longer working after reloading. So I think there are few possibilities:

1. Node has created a new uv loop or iocp after reloading while we are still using the old one. (Unlikely though since other platforms are still working.)
2. Node does some initialization work to the iocp, after reloading the iocp was initialized again and stopped working.
3. After reloading Electron does some cleanup work and breaks iocp.

[codebytere]

@zcbenz determined the true underlying cause - updated the solution & PR body accordingly

[nornagon]

Can we get a test?

[zcbenz]

Test seems to be failing on mac CI:

Error: done() called multiple times
    at IpcMainImpl.<anonymous> (electron/spec-main/api-browser-window-spec.ts:4301:11)
    at Object.<anonymous> (electron/js2c/browser_init.js:157:8980)

[trop]

I was unable to backport this PR to "9-x-y" cleanly;
you will need to perform this backport manually.

[trop]

@codebytere has manually backported this PR to "11-x-y", please check out #25922

[trop]

@codebytere has manually backported this PR to "10-x-y", please check out #25923

[trop]

@codebytere has manually backported this PR to "9-x-y", please check out #25924