While the C based wasm language module inherits the process environment
the Rust based wasm-wasi-component language module did not.

One upshot of this is that with wasm-wasi-component you don't get access
to any environment variables specified in the Unit configuration.

wasm-wasi-component was based on wasmtime 17.0.0. This capability wasn't
added to the wasmtime-crate until version 20.0.0.

Now that wasm-wasi-component has been updated to a newer wasmtime-crate
we can enable this functionality.

Closes: https://github.com/nginx/unit/issues/1312
[ Commit message - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Signed-off-by: Ava Hahn <a.hahn@f5.com>

Bumps <https://github.com/rustls/rustls> from 0.21.10 to 0.21.11.

"This release corrects a denial-of-service condition in
rustls::ConnectionCommon::complete_io(), reachable via network input. If
a close_notify alert is received during a handshake, complete_io() did
not terminate. Callers which do not call complete_io() are not
affected."

The wasm-wasi-component language module is not effected by this as it
doesn't handle client connections, Unit does.

Link: Release notes <https://github.com/rustls/rustls/releases>
Link: Commits <https://github.com/rustls/rustls/compare/v/0.21.10...v/0.21.11>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Bumps h2 <https://github.com/hyperium/h2> from 0.4.2 to 0.4.4.

Limit number of CONTINUATION frames for misbehaving connections.

Link: Changelog <https://github.com/hyperium/h2/blob/master/CHANGELOG.md>
Link: Commits <https://github.com/hyperium/h2/compare/v0.4.2...v0.4.4>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

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>

Bumps mio <https://github.com/tokio-rs/mio> from 0.8.10 to 0.8.11.

Fixes receiving IOCP events after deregistering a Windows named pipe.

Not that that effects Unit...

Link: <https://github.com/nginx/unit/security/dependabot/1>
Link: Changelog <https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md>
Link: Commits <https://github.com/tokio-rs/mio/compare/v0.8.10...v0.8.11>
Signed-off-by: dependabot[bot] <support@github.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
[ Tweaked commit message/subject - Andrew ]
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>