fickle for that, and misleading information wastes oceans of time.

They are grouped by categories and that hasn't changed, and the order
of groups haven't changed. All occurrences of foo.* variables are sorted
alphabetically instead of approximately by relationship between each
other.

Inside the first group, variables are now ordered based on the PROXY
protocol diagram:

- client
- server
- remote
- local

A note was added and is hopefully visible enough to maintain this order.

You can verify that nothing changed:

    $ COMMIT=<this-commit-hash>
    $ git show $COMMIT~:doc/sphinx/reference/vcl_var.rst |
      sed '/^$/d' |
      sort |
      sha1sum
    3400130e88c0456b3bc779b9dfeeff09e130efa3
    $ git show ${COMMIT}:doc/sphinx/reference/vcl_var.rst |
      sed '/^$/d ; /.. NOTE:/d' |
      sort |
      sha1sum
    3400130e88c0456b3bc779b9dfeeff09e130efa3

Use whatever alternative to sha1sum your system may provide.

This reverts commit 82be6f46.

I checked the git history to understand this comment.

And complain when two parameters are passed instead of one parameter and
one option.

Confusing panic output was generated when a worker ran multiple
requests before returning to the pool.

Noticed when debugging #3755 :

  VCL::methods = {RECV, PASS, HASH, MISS, HIT, DELIVER},

Same panic with this fix:

  VCL::methods = {RECV, HASH},

Fixes #3755

I have checked that this catches #3752 too

This is useful to ensure that workspace does not, by chance or
accident, contain data and, in particular, magic numbers from
previous workspace use.

With this change, we can formalize the renaming of a parameter while
maintaining the old name temporarily for compatibility.

A deprecated alias can be set with either param.set or the -p option,
but won't be listed by:

- param.show [-j]
- param.show [-j] changed
- param.show -l

Only an explicit param.show for the name of the alias will provide a
minimal documentation with a deprecation notice and the current value.
In the manual, there is only a deprecation notice. The rationale is
that administration tools shouldn't pick them up when enumerating the
parameters.

Since we currently don't have deprecated parameters, this can only be
tested manually, for example:

    PARAM_ALIAS(vcl_dir, vcl_path)

To ensure that we don't break this, we could consider having a perpetual
deprecated parameter.

Fixes #3752

This reuses the stringform concept and introduces a similar bodyform
flag for STRINGS and BLOB types. We can now assign either a STRING or
a BLOB to [be]resp.body, without breaking the VRT ABI and API. In fact,
the VRT API now uses a void* C type for the BODY VCL type and finds
which type to use based on enum lbody_e.

The enum completely changed but macros were added to maintain the API,
and because of this change, enum lbody_e literals are formatted in two
steps. As a result the BODY type grew another noindent flag. It prevents
the insertion of white space between the LBODY_{ADD,SET}_ prefix and the
type name suffix (BLOB or STRANDS).

This way they can all nicely align in the VTC output.

The recently added "end" legend that denotes the end of a transaction
before a match happened for the given VXID conflicted with the end of
the logexpect spec. The latter was renamed to "done".

When a transaction ends, there will be nothing left to match for the
transaction's VXID. Instead of timing the whole test case out, fail
immediately.

The logics were off by one in the available buffer space checks,
causing us to loose one word of per thread log buffer space, and
making reasoning about available space tricky. Fix this.

Refs 10749ffe
Refs #3745

That is, when it's a request or backend transaction, otherwise it's
still logged with VXID 0. The goal is to allow a correlation between
VCL statements and their workspace footprint by sharing the same
transaction instead of being split between raw and vxid scopes. That
kind of debugging becomes possible when the workspace debug flag is
used and VCL_trace records are not masked.

Given the verbosity of both workspace and trace logs, we would need
new tools to process transactions for this purpose and until we can
link everything we have a chicken-egg problem.

This change does not go all the way and relies on the thread-local
worker reference to opportunistically log into its VSL buffer when
it has one. When the workspace is initialized, the buffer may not
be ready yet, so some logs may still end up raw. What's likely going
to be missing is workspace early initialization and teardown: in other
words before and after VCL execution, which should be good enough for
the purpose of debugging workspace operations in VCL tasks.

Since its primary usage will be workspace logs, workers can be
initialized earlier to offer even more opportunity for logging.

today: VRBT_REMOVE returns the element argument no matter if it was
present in the tree or not, so it can not sensibly be used for assertions.

The old VRT_AddV[DF]P() and VRT_RemoveV[DF]P() are "soft deprecated"
and work the same as previous.  (Hard deprecation after next major.)

Replaced by:
    const char *VRT_AddFilter(VRT_CTX, const struct vfp *, const struct vdp *
    void VRT_RemoveFilter(VRT_CTX, const struct vfp *, const struct vdp *);

VRT_CTX is mandatory.

Both kinds of filters can be handled in one go, but the names must be identical.

VRT_AddFilter returns NULL on success, and VRT_fail'ed error message otherwise.

Supersedes #3287

HSH_Purge() suffers from a problem when there are more objcores on a given
objhead than we can hold temporary references for on the available
workspace, and multiple purges for the same objhead are issued at the same
time.

The previous algorithm would use a flag on the objcores (OC_F_PURGED) in
order to keep track of how far in the list we had gotten. This becomes a
problem when multiple threads are purging the same objhead at the same
time. When a new purge is started, the flags would be reset, which would
cause any existing purge thread to restart. If a steady stream of purges
for a given objhead is issued and enough objcores are present, none would
finish.

This rework uses OC references in the list as bookmarks, in order to know
how far into the list we were when releasing the mutex partway through and
want to resume again. This relies on the list not being reordered while we
are not holding the mutex. The only place where that happens is in
HSH_Unbusy(), where an OC_F_BUSY OC is moved first in the list. This does
not cause problems because we skip OC_F_BUSY OCs.

The OC_F_PURGED flag is removed as it is no longer needed.

The existing r02372.vtc test case exercises this code.