Handle the case where one cannot execute JavaScript

[gabrielschulhof]

Re #30327 #37236

One (somewhat elaborate?) API for semver-minorly handling the inability to execute JS would be the following (somewhat introspective) API:

typedef enum {
  node_api_reason_call_function,
  node_api_reason_throw_exception,
  node_api_reason_open_handle_scope,
  node_api_reason_open_escapable_handle_scope,
  node_api_reason_open_callback_scope,
  ...   // etc.
} node_api_js_exec_failure_reason;

typedef napi_status (*node_api_js_exec_failure_callback)(
    napi_env env,
    node_api_js_exec_failure_reason reason,
    void* reason_data,
    void* user_data);

NAPI_EXTERN napi_status
node_api_handle_js_execution_failure(
    napi_env env,
    node_api_js_exec_failure_callback exec_fail_cb,
    void* user_data);

The add-on maintainer would attach a callback similarly to the napi_set_instance_data finalizer, which would get called whenever we would otherwise return napi_cannot_call_into_js. The callback would analyze the reason and the associated reason_data (which would be a pointer to a stack-allocated structure the type of which depends on reason – a little bit like ioctl(2)) and would return a napi_status that would then be passed as the return value to the original Node-API call.

This could be used to correct a return value of napi_pending_exception from a call to, say, napi_call_function into a return value of napi_ok.

[gabrielschulhof]

@nodejs/node-api ^

[mhdawson]

We discussed another option were we:

• have a method to opt-in to better return codes
  • this could store the setting on the environment
• have a new return code for "not able to call into JavaScript" which is returned if
  the better return codes have been requested.

[mhdawson]

@legendecas also suggested we should investigate if there is any way we can change the sequence of operations so you can executed JS. For example move up in the env teardown sequence.

[gabrielschulhof]

We solved this in #47986 using the new add-on runtime version reporting.