Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.34.0 release.

This resolves a dependabot notification regarding 'idna'.

Link: <https://github.com/nginx/unit/security/dependabot/13>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.34.0 release.

The rustls update fixes a panic in `rustls::server::Acceptor::accept()`,
but Unit does not use this code path and was not affected.

Link: <https://rustsec.org/advisories/RUSTSEC-2024-0399.html>
Link: <https://github.com/nginx/unit/security/dependabot/11>
Closes: <https://github.com/nginx/unit/issues/1503>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

For no real reason other than to be on the latest release for the next
release of Unit...

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

When compiling OTEL support with rustc 1.83.0 we started getting the
following warning

     Compiling otel v0.1.0 (/home/andrew/src/unit/src/otel)
  warning: creating a mutable reference to mutable static is discouraged
    --> src/lib.rs:42:9
     |
  42 |         SPAN_TX.take();
     |         ^^^^^^^^^^^^^^ mutable reference to mutable static
     |
     = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
     = note: mutable references to mutable statics are dangerous; it's undefined behavior if any other pointer to the static is used or if any other reference is created for the static while the mutable reference lives
     = note: `#[warn(static_mut_refs)]` on by default

  warning: `otel` (lib) generated 1 warning
      Finished `release` profile [optimized] target(s) in 1m 07s

However it *seems* our usage is OK, so we can disable this warning
(which it seems will soon turn into a hard error), fortunately we only
need to disable it for the nxt_otel_rs_span_tx() function.

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

Wasmtime 27.0.0 adjusted the C API to start flowing through the
directory and file permission bits of the underlying rust
wasi_config_preopen_dir() implementation.

The directory permissions control whether a directory is read-only or
whether you can create/modify files within.

You always need at least WASMTIME_WASI_DIR_PERMS_READ.

The file permissions control whether you can read or read/write files.

WASMTIME_WASI_FILE_PERMS_WRITE seems to imply
WASMTIME_WASI_FILE_PERMS_READ (but we add both just to make it clear
what we want)

[ Permissions tweak and commit message - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

nxt_cpymem() is basically mempcpy(3)

Like mempcpy() nxt_cpymem() returns a void *.

nxt_cpymem() is implemented as a wrapper around memcpy(3), however
before returning the new pointer value we cast the return of memcpy(3)
to a u_char *, then add the length parameter to it.

I guess this was done to support compilers that do not support
arithmetic on void pointers as the C standard forbids it.

However since we removed support for compilers other than GCC and Clang
(ending in commit 9cd11133 ("Remove support for Sun's Sun Studio/SunPro
C compiler")) this is no longer an issue as both GCC and Clang support
arithmetic on void pointers (without the -pedantic option) by treating
the size of a void as 1.

While removing the unnecessary casting in this case doesn't necessarily
improve type-safety (as we're dealing with void *'s in and out), it does
just make the code that little more readable.

Oh and for interest we have actually already been relying on this
extension

  src/nxt_array.c:143:40: warning: arithmetic on a pointer to void is a GNU extension [-Wgnu-pointer-arith]
    143 |             nxt_memcpy(data, src->elts + (i * size), size);
        |                              ~~~~~~~~~ ^
  src/nxt_string.h:45:24: note: expanded from macro 'nxt_memcpy'
     45 |     (void) memcpy(dst, src, length)
        |                        ^~~

which was introduced in e2b53e16 ("Added "rootfs" feature.") back in
2020.

Link: <https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html>
Link: <https://clang.llvm.org/docs/LanguageExtensions.html#introduction>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Allow format to be an object to generate JSON logs. The object keys
become JSON field names, and values support string, variable, and JS.

Note that when there is no JS in the format values, the object will
be pre-serialized to a JSON template string at configuration phase
for better performance.

Example config:
  {
    "access_log": {
      "path": "/tmp/access.log",
      "format": {
        "remote_addr": "$remote_addr",
        "time_local": "$time_local",
        "request_line": "$request_line",
        "status": "$status",
        "body_bytes_sent": "$body_bytes_sent",
        "header_referer": "$header_referer",
        "header_user_agent": "$header_user_agent"
      }
    }
  }

This is a preparatory refactoring for upcoming JSON format support
in access log. We will extend format option to access object for
JSON support.

No functional changes.

This is a preparatory refactoring for upcoming JSON format support
in access log.

No functional changes.

This is a preparatory refactoring for upcoming JSON format support
in access log.

No functional changes.