As opposed to special values. This enables setting "absolute" values
atomically:

    param.set foo none,+bar,+baz

The most significant bits of the least significant octet would be
omitted when the number of bits is not a multiple of eight.

Cli command '"help" "help"' was wrongly rejected with error
message: "Missing separator between arguments"

Output before:

PASS: <> with flags 7 as expected.
PASS: <foo> with flags 0 as expected.
PASS: <foo bar> with flags 0 as expected.
PASS: <foo bar> with flags 2 as expected.
PASS: <foo,bar> with flags 2 as expected.
PASS: <  foo  bar  > with flags 0 as expected.
PASS: <  foo  ,  bar  > with flags 2 as expected.
PASS: <foo bar > with flags 2 as expected.
PASS: <foo,bar,> with flags 2 as expected.
PASS: <foo "bar baz"> with flags 0 as expected.
PASS: <foo #bar> with flags 0 as expected.
PASS: <foo #bar> with flags 1 as expected.
PASS: <foo#bar> with flags 0 as expected.
PASS: <foo#bar> with flags 1 as expected.
PASS: <\> with flags 4 as expected.
PASS: <\x20> with flags 0 as expected.
PASS: <foo"bar> with flags 4 as expected.
PASS: <"foo""bar"> with flags 4 as expected.

Output after:

PASS: <> with flags 7 as expected.
PASS: <foo> with flags 0 as expected.
PASS: <foo bar> with flags 0 as expected.
PASS: <foo bar> with flags 2 as expected.
PASS: <foo,bar> with flags 2 as expected.
PASS: <  foo  bar  > with flags 0 as expected.
PASS: <  foo  ,  bar  > with flags 2 as expected.
PASS: <foo bar > with flags 2 as expected.
PASS: <foo,bar,> with flags 2 as expected.
PASS: <foo "bar baz"> with flags 0 as expected.
PASS: <foo #bar> with flags 0 as expected.
PASS: <foo #bar> with flags 1 as expected.
PASS: <foo#bar> with flags 0 as expected.
PASS: <foo#bar> with flags 1 as expected.
PASS: <\> with flags 4 as expected.
FAIL: <\> with flags 0 as expected.
FAIL: <\x> with flags 0 as expected.
FAIL: <\x2> with flags 0 as expected.
FAIL: <\x2O> with flags 0 as expected.
PASS: <\x20> with flags 0 as expected.
FAIL: <"foo> with flags 0 as expected.
PASS: <foo"bar> with flags 4 as expected.
FAIL: <foo"bar> with flags 0 as expected.
FAIL: <foo"bar> with flags 0 as expected.
PASS: <"foo""bar"> with flags 4 as expected.
FAIL: <"foo""bar"> with flags 0 as expected.

Currently, vav_test always passes make check

We've had contextual min/max/default values in the param.show and
param.set output and the manual for a while now.

we can not make the parameter const because API.

(sorry)

as agreed on IRC.

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