Unfortunately, the units passed to
monotime_coarse_stamp_units_to_approx_msec() was always 0 due to a type
conversion.

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

This commit introduces the consensus parameter "circ_max_cell_queue_size"
which controls the maximum number of cells a circuit queue should have.

The default value is currently 50000 cells which is above what should be
expected but keeps us a margin of error for padding cells.

Related to this is #9072. Back in 0.2.4.14-alpha, we've removed that limit due
to a Guard discovery attack. Ticket #25226 details why we are putting back the
limit due to the memory pressure issue on relays.

Fixes #25226

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

We removed this file, but didn't take it out of EXTRA_DIST -- thus
breaking "make dist".

"ours" to avoid version bump.

Both header and code file had some indentation issues after mass renaming.

No code behavior change.

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

Really, the uint32_t is only an optimization; any kind of unit
should work fine.  Some users might want to use time_t or
monotime_coarse_t or something like that.

(These functions were previously helper functions for
token_bucket_rw_t).

(The tests caught this one.)

Begin by creating a lowest-level triple of the types needed to
implement a token bucket: a configuration, a timestamp, and the raw
bucket itself.

Note that for low-level buckets, the units of the timestamp and the
bucket itself are unspecified: each user can use a different type.

(This patch breaks check-spaces; a later patch will fix it)

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

Add to the Denial of Service section of the man page an explanation about the
three different mitigation Tor has.

Fixes #25248.

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

(This function is no longer used.)

This is a simple search-and-replace to rename the token bucket type
to indicate that it contains both a read and a write bucket, bundled
with their configuration.  It's preliminary to refactoring the
bucket type.

This test works by having two post-loop events activate one another
in a tight loop.  If the "post-loop" mechanism didn't work, this
would be enough to starve all other events.

This is a second motivating case for our postloop event logic.

A linked connection_t is one that gets its I/O, not from the
network, but from another connection_t.  When such a connection has
something to write, we want the corresponding connection to run its
read callback ... but not immediately, to avoid infinite recursion
and/or event loop starvation.

Previously we handled this case by activating the read events
outside the event loop.  Now we use the "postloop event" logic.
This lets us simplify do_main_loop_once() a little.

We've been labeling some events as happening "outside the event
loop", to avoid Libevent starvation.  This patch provides a cleaner
mechanism to avoid that starvation.

For background, the problem here is that Libevent only scans for new
events once it has run all its active callbacks.  So if the
callbacks keep activating new callbacks, they could potentially
starve Libevent indefinitely and keep it from ever checking for
timed, socket, or signal events.

To solve this, we add the ability to label some events as
"post-loop".  The rule for a "post-loop" event is that any events
_it_ activates can only be run after libevent has re-scanned for new
events at least once.