The discrepancy in ReqAcct is due to changes in Varnish master since
about December 2020, which have evidently not been backported to
6.0. See commit e4fd1761.

- RST formatting changes in README
- Old naming conventions from the vmodtool.
  - We define VENUM() ourselves
- struct vmod_priv for BLOB
- No type field for BLOBs
- req->top->topreq is just req->top
- Changed Debug log format from the shard
  director

XXX esi.vtc is subtly different in the expected
ReqAcct numbers, due to different response header
sizes. See the two XXXs in the VTC file.

This is *not* because of the header that shouldn't
be there according to the test, that's checked in
the test, and it doesn't appear in the log.

I suspect that this difference is irrelevant, but
have am going ahead with the commit despite the
uncertainty.

Ref:
https://github.com/varnishcache/varnish-cache/commit/681c11998ec56dc4460a30585210f95a7850ea3b

Ref: https://github.com/varnishcache/varnish-cache/commit/5450550906d0809dfc21ae9d3a5b14446c1809d4

Ref:    d67993451bda7eeb7c0ea3c5528a8353f283a190

This reverts commit 5829411d.

ref: 0c74d1b99f1f43fc99725fe14322760afa7858ee

Ref: e8985f22711fe9a342b27a10052ae3655f64435c

ref https://github.com/varnishcache/varnish-cache/issues/2840

ref https://github.com/varnishcache/varnish-cache/issues/2840

The reason is the same as for
https://github.com/varnishcache/varnish-cache/issues/2708 :

VRT_priv_task may now return NULL for out-of-workspace errors, see
https://github.com/varnishcache/varnish-cache/commit/de2b431086a13b243dc8b3e71cd8697db1df2c7f

A Host: header is now added always, which accounts for another
17 bytes for connections to 127.0.0.1

The purpose of these tests was to ensure that vmod_blobcode works identical
to shard.key(). Now that the latter has been changed to only support SHA256,
we need to remove out tests for custom hashes.

Ref: https://github.com/varnishcache/varnish-cache/pull/2558

varnish-cache commit 51176640603b123a38b49ae271cb9c9de9df1d28