Adding --trace-sigint for tests that are timing out in tools/test.py?

[joyeecheung]

It seems recently many flakes are tests that are timing out. In this case, in the CI we usually see nothing but a hint that it is failing because of a timeout. It seems useful to either always run the tests with --trace-sigint, or support re-running the test immediately with --trace-sigint once it times out. (another option would be to use a stress test job separately, but not all configs are supported in stress tests)

Some caveats:

1. This may work well enough at least for tests that are not timing out because a child process is timing out. For the child process case, maybe it's useful to implement a dedicated environment variable for this (I think simply using NODE_OPTIONS might not be enough since the tests might not be concatenating what's from the environment).
2. --trace-sigint is implemented in JS and is only printing the main thread's JS stack trace. In this use case I think we are very likely to need the native stack traces too, and for all threads.
3. Maybe an option built into Node.js isn't the most robust approach and we should implement something external for this?

cc @nodejs/build @nodejs/testing @legendecas (who implemented --trace-int)

[legendecas]

Always run the tests with --trace-sigint sounds good to me. I will make it print native stack as well.

However, it will not be helpful if the tests are timed out for non busy-loops, like the child process case, and I believe waiting on external resources will be most of the cases (no exact figures at the moment, could be a false assumption).

[joyeecheung]

Actually, on Linux there's eu-stack from elfutils that can dump the native stack traces of all threads in a given process. Not sure about other platforms, or whether it's feasible to install them in our CI infra, though. In addition I think having JS stack traces are still useful..