This will allow per-session adjustments and also significantly
lower the risk of inconsistent calculations in the rate limit
code during parameter changes.

Ref #3996

to anchor patches

Noticed while porting #3998 to the 6.0 branch with a varnishtest more
sensitive to timing.

With #3998 we need to ensure streams are not going to skip vcl_recv if
reset faster than reaching this step for the request task.

The alternative to prevent the vcl_req_reset feature from interfering
is to simply disable it.

The error check is not performed in a critical section to avoid
contention, at the risk of not seeing the error until the next
transport poll.

Once a client is reportedly gone, processing its VCL task(s) is just a
waste of resources. The execution of client-facing VCL is intercepted
and an artificial return(fail) is returned in that scenario.

Thanks to the introduction of the universal return(fail) proper error
handling and resource tear down is already in place, which makes this
change safe modulus unknown bugs. This adds a circuit breaker anywhere
in the client state machine where there is VCL execution.

A new Reset time stamp is logged to convey when a task does not complete
because the client is gone. This is a good complement to the walk away
feature and its original circuit breaker for the waiting list, but this
has not been integrated yet.

While the request is technically failed, it won't increase the vcl_fail
counter, and a new req_reset counter is incremented. This new behavior
is guarded by a new vcl_req_reset feature flag, enabled by default.

Refs #3835
Refs 61a15cbf
Refs e5efc2c8
Refs ba54dc91
Refs 6f50a00f
Refs b8816994

The goal is for top-level transports to report whether the client is
still present or not.

It was particularly hard to follow once we reach client c3.

Only RST frames received earlier than this duration will be considered
rapid.

This adds parameters h2_rst_allowance and h2_rst_allowance_period,
which govern the rate of which we allow clients to reset h/2 streams.

If the limit is exceeded the connection is closed.

Mitigates: #3996

Fixes #3995

Fixes: 3995

this is required for autoconf 2.71, but I have kept the required
version at 2.69 and tested that the changes are compatible.

Most of the changes come from autoupdate, with this change:

AC_PROG_CC_STDC is obsolete, but older autoconf versions
do not set the highest possible c standard.

So we keep AC_PROG_CC_C99 because we actually require
c99, while AC_PROG_CC_STDC could fall back to c89

For varnish.m4, we should apply the same canonical settings
as for varnishd itself

... except for ax_with_curses.m4 which requires PKG_CHECK_EXISTS which,
apparently, cci does not have

should we consider again to not have them and rather require autoconf-archive
be installed?

Otherwise we end up with a broken output outside of MacOS:

    checking whether daemon() works... checking for daemon... yes

Now it's one or the other:

    checking whether daemon() works... no
    checking for daemon... yes

If we want to lie, we should at least be good at it.

By conditionally setting vmod_*_vcc variables in includes we can get rid
of a double definition warning.

Feedback from Dridi and a Flexelint warning.

Ref 91a85840

most of all, this will make a helpful errno value available to the
caller.

seen with an edgecase vtc, not relevant for production, but still a fix
nevertheless.

Adds coverage for tab characters at start/end of field value.

Regarding the "fo o" " bar" header, it cumulates an error in the name
and another in the value, but only one of them will trigger the expected
PROTOCOL_ERROR. Only the invalid "fo o" is checked now, and the other
error is part of the new coverage.
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Control characters will be caught by vct_ishdrval() anyways, but this
condition would also reject allowed obs-text non-ASCII characters.
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Refs #3984

Closes #3984

Refs #3984

Refs #3984