We actually changed behavior also for vcc_acl_pedantic=false

And a quick note on the workspace API plus homework for later.

Yes, I missed at least one varnishd change in my first pass.

Leaving out any change that is solely a bug fix on purpose.

The only user-visible change for this release.

I thought the slight change of behavior was worth mentioning, and that in
the varnishadm/CLI section it would stand out.

Whether the header was set by the backend or directly in VCL, it is now
possible to signal that a backend connection should not be added back to
the pool after a successful fetch with a Connection:close header.

Pooling such a connection would be counter-productive if closing the
session was requested by the backend itself, because it would then be
likely that reusing the connection would result in busting the extra
chance.

Setting the Connection:close directly in VCL can help mitigating against
a misbehaving backend.

Refs #3400

And amend the 7.0.0 mis-prediction.

Which isn't that many when you omit VCL.

In addition, soften the WS_Front() deprecation and keep the new WS_Id()
function internal.

Varnish uses a global per-probe timeout for backend probes. When reading
the backend response, Varnish tries to poll and read in a loop, until a
poll timeouts, the streams EOFs or there is an error.

The poll is supposed to timeout when the per-probe timeout ends. This is
currently setup so that `t_end` is the deadline for the probe, set when
the function starts, then the poll waits until `t_end`.

Previously, the poll timeout was never updated, and was always set to
`t_end - t_now` without updating `t_now`, which means that it was
effectively a between-bytes timeout instead of a proper per-probe
timeout.

This fixes this issue by updating `t_now` before updating the
`t_end - t_now` timeout so that the timeout passed to poll effectively
corresponds to a deadline of `t_end`.

See the issue fixed by this commit for more details.

Fixes: #3402

Give WS_Reservation() the same "always return non-NULL or assert"
semantics WS_Front() had because literally every single caller which
uses the ->f pointer fails to check for NULL.

Introduce a new internal WS_IsReserved() for use in the asserts
which check if a reservation is active, but which doesn't otherwise
care for the ->f pointer, and the single instance of non-WS code
which (possibly) legitimatly does variant processing depending on
the reservation state.

It has been a while since the built-in vcl_hit changed, and this
updates the user guide.

Since 6.0.1 we have had the corresponding change in TTL, grace, keep
change, and this is also mentioned.

It may define macros recognized by other includes.

Spotted by @gquintard

It used to be relevant before we had WS_Id().

We might read past the end of the workspace when no space was available
at reservation time. This would normally go unnotticed since we used to
get zeros after the end of workspace marker, and no assertion would
trigger. It became visible with the previous commit for pointer-aligned
workspace sizes like the current page-aligned default values.

Initially caught by wssan from #3320.

Fixes #3319

It might help catch more buffer overflows, although we still only check
the first byte.

The offset must be strictly lower than 0xffff, otherwise subsequent get
and set operations will ignore it. Instead of panicking, we release the
workspace and carry on if that happens.

This is only for correctness' sake, the probability to run into this is
epsilon.

From this point on, only cache_ws.c fiddles with struct ws, which needs
to remain visible in order to be embeddable in other data structures. We
have an API covering all use cases in tree, except vmod_vtc operations
that violate the contract to provide a rudimentary dump in VCL for test
purposes.

Inline functions provided in headers aren't considered a problem here.

The goal is to avoid direct field access inside struct ws outside of
cache_ws.c and open the possibility to perform a hexdump of a corrupted
allocation in the future, when wssan panics while checking red zones.

This effectively completes the ban of direct field access to the front,
start and reservation pointers outside of cache_ws.c, and since the
devil is in the details cache_http.c directly touches the id field and
vmod_vtc also accesses the 3 aforementioned pointers.