Start to add rust backed request execution under a feature-flag by rewriting ConfigRequest

[yamadapc]

Does not achieve anything in particular other than set patterns for exposing/integrating rust code under a flag.

While implementing unit-tests for the ConfigRequest I found a bug where invalidateOnEnvChange would not be picked-up on its own.

There are exhaustive tests for the config request current/previous implementations added.

For the hashing section, there is a slight missing part regarding sorting of object keys.

[devongovett]

I actually want to remove ConfigRequest completely. It's not a real request at the moment actually since it doesn't do any work. The configs have actually already been loaded, and the ConfigRequest is fake just to setup the request graph structure. In reality, it isn't necessary at all - the invalidations could just be added to the parent request. The config loading doesn't get invalidated separately right now anyway.

In addition, it looks like there's a lot of bridging here. Since ConfigRequest doesn't actually do any work other than mutating the graph, now we're calling into rust only to call back into JS several times. Maybe ConfigRequest was just an example of the setup but perhaps it would be more efficient to do the request work in rust and send back all the invalidations at once as part of the result rather than calling back to JS via the RequestApi a whole bunch of times?

[yamadapc]

That makes sense; the purpose of this PR is:

• Start migrating
• Show JS delegation / interop patterns we can use
• Write tests

Maybe ConfigRequest was just an example of the setup but perhaps it would be more efficient to do the request work in rust and send back all the invalidations at once as part of the result rather than calling back to JS via the RequestApi a whole bunch of times?

Yes this is just an example so it doesn't do anything interesting.

That said, I feel strongly we should not optimise anything without measuring. The benchmarks added in https://github.com/yamadapc/napi-benchmark/tree/main show there's very low overhead to call JavaScript functions from rust (nanosecond cost for calls in of themselves).

Optimising without benchmarks or measurements has a high risk of implementing something that is at the same time hard to understand and that potentially isn't faster than a naive implementation.

[alshdavid]

What problem would be solved by locking a Rust thread but calling into JS from a background thread?

Essentially, for every 1 JavaScript execution context/worker, napi demands 1 dedicated Rust thread. You cannot pass JavaScript references between threads (with some exceptions) so data is typically handled through channels. If you want to do non blocking JS behaviours, that must be factored into the way you write the napi bindings and is quite verbose.