This fixes an issue we had with wasm-wasi-component failing to load
components with

  2024/11/06 21:08:50 [alert] 107196#107196 failed to create initial state

  Caused by:
      0: failed to compile component
      1: WebAssembly translation error
      2: Invalid input WebAssembly code at offset 15936: zero byte expected

Which was a symptom of
<https://github.com/bytecodealliance/wasmtime/issues/9130>

Closes: https://github.com/nginx/unit/issues/1477
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Bumps <https://github.com/bytecodealliance/wasmtime> from 24.0.0 to
24.0.1.

Fixes:

  a runtime crash when combining tail-calls with host imports that
  capture a stack trace or trap. GHSA-q8hx-mm92-4wvg

  a race condition could lead to WebAssembly control-flow integrity and
  type safety violations. GHSA-7qmx-3fpx-r45m

Link: Release notes <https://github.com/bytecodealliance/wasmtime/releases>
Link: Changelog <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-some-possible-changes.md>
Link: Commits <https://github.com/bytecodealliance/wasmtime/compare/v24.0.0...v24.0.1>
Signed-off-by: dependabot[bot] <support@github.com>
[ Tweaked commit message/subject - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

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>