Add QuickJS as a Javascript engine option
https://bellard.org/quickjs
Some benefits over SM:
* Small. We're using 6 or so C files vs 700+ SM91 C++ files.
* Built with Apache CouchDB as opposed having to maintain a separate SM
package, like for RHEL9, for instance, where they dropped support for SM
already. (see https://github.com/apache/couchdb/issues/4154).
* Embedding friendly. Designed from ground-up for embedding. SM has been
updating the C++ API such that we have to keep copy-pasting new versions of
our C++ code every year or so. (see
https://github.com/apache/couchdb/pull/4305).
* Easy to modify to accept Spidermonkey 1.8.5 top level functions for
map/reduce code so we don't have have to parse the JS, AST transform it, and
then re-compile it.
* Configurable runtime feature set - can disable workers, promises and other
API and features which may not work well in a backend JS environment. Some
users may want more, some may want to disable even Date(time) features to
hedge again Spectre-style attacks (spectreattack.com).
* Allows granular time (reduction) tracking if we wanted to provide a runtime
allowance for each function.
* Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so
we can afford to do that on reset. JSRuntimes cannot share JS data or object
between them.
* Seems to be faster in preliminary benchmarking with small
concurrent VDU and view builds:
https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758
Results seem promising:
- 4x faster than SM 1.8.5
- 5x faster than SM 91
- 6x reduced memory usage per couchjs process (5MB vs 30MB)
* Allows compiling JS bytecode ahead of time a C array of bytes.
QuickJS can be built alongside Spidermonkey and toggled on/off at runtime:
```
./configure --dev --js-engine=quickjs
```
This makes it the default engine. But Spidermonkey can still be set in the
config option.
```
[couchdb]
js_engine = spidermonkey | quickjs
```
To test individual views, without switching the default use the
`javascript_quickjs` language in the design docs. To keep using Spidermonkey
engine after switching the default, can use `javascript_spidermonkey` language
in design docs. However, language selection will reset the view and the view
will have to be rebuilt.
It's also possible to build without Spidermonkey support completely by using:
```
./configure --disable-spidermonkey
```
Issue: https://github.com/apache/couchdb/issues/4448
Fix invalid call to exit/2 in couch_server
Previously we called it as `exit(couch_server_N, config_change)` but exit/2
doesn't know what to do with an atom, it needs a pid.
```
exit(couch_server_1, foo).
** exception error: bad argument
in function exit/2
called as exit(couch_server_1,foo)
*** argument 1: not a pid
```
This doesn't actually restart the servers as intended and it's also making
quite a mess in the eunit logs.
In addition to ensuring we're calling a Pid, use a `{shutdown, _}` error shape
to avoid triggering verbose SASL report as it's an expected condition.
