Perform graceful termination on SIGINT or SIGTERM signals

[lpsinger]

Thank you for helping out! ✨

We really appreciate your commitment to improving Architect

To maintain a high standard of quality in our releases, before merging every pull request we ask that you've completed the following:

• Forked the repo and created your branch from main
• Made sure tests pass (run npm it from the repo root)
• Expanded test coverage related to your changes:
  • Added and/or updated unit tests (if appropriate)
  • Added and/or updated integration tests (if appropriate)
• Updated relevant documentation:
  • Internal to this repo (e.g. readme.md, help docs, inline docs & comments, etc.)
  • Architect docs (arc.codes)
• Summarized your changes in changelog.md
• Linked to any related issues, PRs, etc. below that may relate to, consume, or necessitate these changes

Please also be sure to completed the CLA (if you haven't already).

Learn more about contributing to Architect here.

Thanks again!

[ryanblock]

Sorry, I have a number of issues here. We shouldn't be using esm-only modules, as our stuff is, for now, still authored in CJS. import is async, so this is a bit wonky here, and may present some funky / non-deterministic scenarios during testing.

Moreover, we will not be adding any new libraries by Sindre moving forward after his actions during the CJS/ESM debacle. (We'll eventually phase the ones still in use.) Finally, I'm not sure what this is really buying us here, and I'm much more inclined to just attempt to handle signals as necessary (or simply use process.on('exit', fn) if possible).

[ryanblock]

@lpsinger did you still want to look at this?

[lpsinger]

Yes, this is still a serious problem for a project.

[ryanblock]

Ok! Just in case you missed it from architect/architect#1479 (comment):

process.on('exit', ...), process.on('SIGINT', ...), process.on('SIGTERM', ...) are all assumed to be synchronous operations, whereas sandbox.end() is an asynchronous API (which is what I think folks would expect it to be).

I've got a short window this morning, I'll take a quick look at an implementation in another PR.

[ryanblock]

→ #732

[ryanblock]

Best effort attempt at fixing this (within Arc's scope / capabilities) live in v11.0.8!