<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
  * 5.0.12 - 7.1.10
* **Operating System:**
  * Windows 10/macOS 10.15
* **Last Known Working Electron version:**
  * 4.2.5

### Expected Behavior
We have been using the piece of code to perform asynchronous operations.
```js
await new Promise((resolve) => { setTimeout(resolve, 1000); }
```
It would pause the execution of the code path containing it for about 1 second and resume it then. This has been working well for a long time.

### Actual Behavior
Since we upgrade to Electron 7, in forked node processes, only the first several timer callbacks are called on time, while the rest of them are called extremely late for unknown reason.

Suppose we call the above piece of code for 10 times in a loop. Only the first two promises are created and resolved correctly. In addition, the process exits for unknown reason. In our production code, since there are other things going on (not computationally intensive) which keeps the process alive, we are seeing the 3rd and the rest of the Timers being created and invoked unreasonably late (around 12s after the 2nd one resolves).

The output in the renderer console is
```
Spawned child process <some_pid>
child process send a message INIT_ACK
child process send a message INIT_ACK
child process exits
```

### To Reproduce
https://github.com/JasonYeMSFT/electron-quick-start/tree/bug/await-Promise

To run the repro steps
```sh
$ git clone https://github.com/JasonYeMSFT/electron-quick-start -b bug/await-Promise
$ npm install
$ npm start
```
<!--
If you provide a URL, please list the commands required to clone/setup/run your repo e.g.
```sh
$ git clone $YOUR_URL -b $BRANCH
$ npm install
$ npm start || electron .
```
-->

### Screenshots
<!-- If applicable, add screenshots to help explain your problem. -->

### Additional Information
Electron 4.2.5 behaves correctly for exactly the same code in this repo. The behavior doesn't reproduce in renderer process. Also it doesn't seem to be a nodejs problem because I can run the renderer.js directly with node on the same version and it behaves correctly.

I did some extra experiment and it turns out that `setInterval` is producing much more stable behaviors compared to `setTimeout` (update, I was wrong, `setInterval` also has the weird behavior).
shell/app/node_main.cc
base::CommandLine::Init(argc, argv);
  int exit_code = 1;
  {
    
    argv = uv_setup_args(argc, argv);
    uv_loop_t* loop = uv_default_loop();
    scoped_refptr<UvTaskRunner> uv_task_runner(new UvTaskRunner(loop));
    base::ThreadTaskRunnerHandle handle(uv_task_runner);
    
    auto feature_list = std::make_unique<base::FeatureList>();
    feature_list->InitializeFromCommandLine("", "");
    base::FeatureList::SetInstance(std::move(feature_list));
#if defined(_WIN64)
    crash_reporter::CrashReporterWin::SetUnhandledExceptionFilter();
#endif
    
    NodeBindings::RegisterBuiltinModules();
    
    SetNodeCliFlags();
    int exec_argc;
    const char** exec_argv;
    node::Init(&argc, const_cast<const char**>(argv), &exec_argc, &exec_argv);
    gin::V8Initializer::LoadV8Snapshot(
        gin::V8Initializer::V8SnapshotFileType::kWithAdditionalContext);
    
    base::ThreadPoolInstance::CreateAndStartWithDefaultParams("Electron");
    
    JavascriptEnvironment gin_env(loop);
    v8::Isolate* isolate = gin_env.isolate();
    v8::Isolate::Scope isolate_scope(isolate);