Liam reported a problem when trying to restart wasm-wasi-component based
applications using the /control/applications/APPLICATION_NAME/restart
endpoint.

The application would become unresponsive.

What was happening was the old application process(es) weren't
exit(3)ing and so while we were starting new application processes, the
old ones were still hanging around in a non-functioning state.

When we are terminating an application it must call exit(3).

So that's what we do. We use the return value of nxt_unit_run() as the
exit status.

Due to exit(3)ing we also need to now explicitly handle the return on
error case.

Reported-by: Liam Crilly <liam@nginx.com>
Fixes: 20ada4b5c ("Wasm-wc: Core of initial Wasm component model language module support")
Closes: https://github.com/nginx/unit/issues/1179
Tested-by: Liam Crilly <liam@nginx.com>
Tested-by: Danielle De Leo <d.deleo@f5.com>
Co-developed-by: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

The variables accessed with JS template literal should not be cacheable.
Since it is parsed by njs engine, Unit can't create indexes on these
variables for caching purpose. For example:

   {
       "format": "`{bodyLength:\"${vars.body_bytes_sent}\",status:\"${vars.status}\"}\n`"
   }

The variables like the above are not cacheable.

Closes: https://github.com/nginx/unit/issues/1169

This exposes the various WebAssembly Component Model language module
specific options.

The application type is "wasm-wasi-component".

There is a "component" option that is required, this specifies the full
path to the WebAssembly component to be run. This component should be in
binary format, i.e a .wasm file.

There is also currently one optional option

"access"

Due to the sandboxed nature of WebAssembly, by default Wasm
modules/components don't have any access to the underlying filesystem.

There is however a capabilities based mechanism[0] for allowing such
access.

This adds a config option to the 'wasm-wasi-component' application type
(same as for 'wasm');
'access.filesystem' which takes an array of
directory paths that are then made available to the wasm
module/component. This access works recursively, i.e everything under a
specific path is allowed access to.

Example config might look like

  "applications": {
      "my-wasm-component": {
          "type": "wasm-wasi-component",
          "component": "/path/to/component.wasm",
          "access" {
              "filesystem": [
                  "/tmp",
                  "/var/tmp"
              ]
          }
      }
  }

The actual mechanism used allows directories to be mapped differently in
the guest. But at the moment we don't support that and just map say /tmp
to /tmp. This can be revisited if it's something users clamour for.

[0]: <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

It seems we do want to track this thing. This is just the latest version
that cargo had generated for me.

Cc: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

With the initial port to wasmtime 17 we could no longer use the
'reactor' adaptor but had to switch to the more restrictive 'proxy'
adaptor.

This meant amongst other things (probably) we could no longer access the
filesystem.

Thanks to Joel Dice for pointing out the fix.

With this we can go back to using the 'reactor' adaptor again and things
are back to working as before.

It's worth noting that you can use either the 'proxy' or 'reactor'
adaptor depending on your requirements.

Cc: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This brings WASI 0.2.0 support.

Link: <https://github.com/bytecodealliance/wasmtime/releases/tag/v17.0.0>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

When Unit receives a request, if the body of that request is greater
than a certain amount (16KiB by default) then it is written to a
temporary file.

When a language module goes to read the request body in such situations
it will end up using read(2).

The wasm-wasi-component language module was failing to properly read
request bodies of around 2GiB or more.

This is because (on Linux at least) read(2) (and other related system
calls) will only read (or write) at most 0x7ffff000 (2,147,479,552)
bytes, this is the case for both 32 and 64-bit systems.

Regardless, it's probably not a good idea doing IO in such large chunks
anyway.

This patch changes the wasm-wasi-component language module to read the
request buffer in 32MiB chunks (this matches the original 'wasm'
language module).

We are still limited to a 4GiB address space and can only upload files a
little under 4GiB.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Run from the repository root like

  $ rustfmt --edition 2021 src/wasm-wasi-component/src/lib.rs

Also manually fix up some overly long comments.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This is the work of Alex Crichton.

This is written in Rust. The problem is that there is currently no
support on the C side of things for the component model, which is the
point of this module.

It talks to Unit via automatically generated bindings.

I've (Andrew) just made some minor tweaks to src/lib.rs, build.rs &
Cargo.toml to adjust some paths, adjust where we get the language module
config from and the module name and where it's located in the source
tree,

I also removed and disabled the tracking of the Cargo.lock file, this is
constantly changing and not tracking it seems right for 'libraries' and
dropped the README's...

Other than that I have tried to leave his work intact, subsequent
commits will make some larger changes, but I didn't want to intermix
them with Alex's work.

One such commit will update the module to use wasmtime 17 which brings
WASI 0.2.0 support.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This is required to actually _build_ the 'wasm-wasi-componet' language
module.

The nxt_wasm_wc_app_conf_t structure consists of the component name, e.g
my_component.wasm, this is required. It also consists of an object to
store the directories that are allowed access to by the component, this
is optional.

The bulk of the configuration infrastructure will be added in a
subsequent commit.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>