With this commit, a relay now emits metrics event on the MetricsPort
related to how many onionskins were handled (processed or dropped) for
each handshake type.

Related to #40367

Signed-off-by: David Goulet <dgoulet@torproject.org>

With this commit, a relay now emits metrics event on the MetricsPort
related to the OOM invocation for:

  - DNS cache
  - GeoIP database
  - Cell queues
  - HSDir caches

Everytime the OOM is invoked, the number of bytes is added to the
metrics counter for that specific type of invocation.

Related to #40367

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

The basic functions for the relay subsystem to expose metrics onto the
MetricsPort.

Part of #40367

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

It is a common function that a lot of subsystem can use which is to
format a label so move it out of the HS subsystem into the more generic
metrics library.

Signed-off-by: David Goulet <dgoulet@torproject.org>

An entry can have multiple labels but only print once the comments at
the first one. This follows the Promtheus best practices.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Patch from cypherpunks. Closes #40330.

"ours" to avoid version bump.

"ours" to avoid version bump.

This patch unbreaks the current build after tor!369 landed.

See: https://bugs.torproject.org/tpo/core/tor/40371

This change permits the newfstatat() system call, and fixes issues
40382 (and 40381).

This isn't a free change.  From the commit:

    // Libc 2.33 uses this syscall to implement both fstat() and stat().
    //
    // The trouble is that to implement fstat(fd, &st), it calls:
    //     newfstatat(fs, "", &st, AT_EMPTY_PATH)
    // We can't detect this usage in particular, because "" is a pointer
    // we don't control.  And we can't just look for AT_EMPTY_PATH, since
    // AT_EMPTY_PATH only has effect when the path string is empty.
    //
    // So our only solution seems to be allowing all fstatat calls, which
    // means that an attacker can stat() anything on the filesystem. That's
    // not a great solution, but I can't find a better one.

As of GCC 11.1.1, the compiler warns us about code like this:

     if (a)
         b;
         c;

and that's a good thing: we wouldn't want to "goto fail".  But we
had an instance if this in circuituse.c, which was making our
compilation sad.

Fixes bug 40380; bugfix on 0.3.0.1-alpha.

"ours" merge to avoid version bump.

"ours" to avoid version bump.