cache/cache_vrt.c  916  Warning 438: Last value assigned to variable
'berr' (defined at line 849) not used

berr is intentionally NULLed to clarify that no dynamic value must stay
alive after the BAN_Abandon()

Ref 6eee0074

Ref
https://github.com/varnishcache/varnish-cache/pull/3486#issuecomment-754019262

roadmap:

 v/ add std.ban*(),
    add implicit import std
    vcc aliases ban() to std.ban() (some concerns raised)
 v/ deprecated ban() without std.
    remove ban() without std.

from
https://github.com/varnishcache/varnish-cache/pull/3486#pullrequestreview-561662742

as that ticket is closed now

The ban() vcl action adds bans like the ban CLI command, but has no
facility for in-band error reporting. Errors are only reported to VSL.

We add std.ban() as a replacement for ban() with identical semantics,
but returning if the ban was successfully added.

std.ban_error() is added to report the error, if any.

We add v00009.vtc mirroring v00011.vtc, but with std.ban() replacing
ban(). The test number was chosen to fill a gap close to v00011.vtc.

Implementation:

We change VRT_ban_string() to return any error or NULL for
success. Where the error is not a constant string, we need to format
it on the workspace. For workspace overflows, we need to fall back to
canned constant error strings to ensure that the error case never
appears as success.

Pull out determining the privs head

Re-use will come with a PR

pointed out by Dridi in #3486

introduced by /me in 6cf1138f

Ref Coverity CIDs 1362617, 1362618, 1362624, 1362626

Spotted by local Flexelint install on Linux

cache_varnishd.h already includes:
- sys/socket.h
- string.h

Spotted by local Flexelint install on Linux

Apple's clang calls dsymutil(1) when -g is used, creating a
<binary>.dSYM directory which breaks this test. As I haven't found
a way to disable it just ignore this check if the directory is
present.

Ref CID 1400491

Ref CID 1430127, CID 1430118

3a5af972 enabled flexelint to complain
about copying many bytes into a struct member declared as a
single byte array (which it never was).

warning addressed:

proxy/cache_proxy_proto.c  469  Warning 669: Possible data overrun for
function
    'memcpy(void *, const void *, unsigned long)', argument 3 (size=988)
    exceeds argument 1 (size=1) [Reference: file proxy/cache_proxy_proto.c:
    lines 340, 348, 392, 401, 410, 439, 469]

ref. coverity CID 1430125

We reported any PROXY connection failure as JUNK. Now we report the same
reasons as for failing HTTP1 connections.

Implmentation:

SES_DeleteHS() asserts that the hs argument be negative (one of
JUNK, CLOSE, TIMEOUT, OVERFLOW, EOF).

HTC_RxStuff() may return OVERFLOW, JUNK, COMPLETE, EOF or TIMEOUT (or,
instead of TIMEOUT, IDLE if the callback returned EMPTY).

Because vpx_complete() only returns JUNK, OVERFLOW or MORE, using
the HTC_RxStuff() return value for SES_DeleteHS() is safe if different
from COMPLETE.

adds handling of HTC_S_JUNK

Coverity CID 1099620

reported by coverity

This is to chase a new case of the watchdog off the leash

more re-use coming up in a PR

seen in vtest:

**   l1    Waiting for logexp
**** dT    1.477
**** l1    match|       1016 BogoHeader      c Missing header name: : Header
***  l1    expecting| expect * 1018 VCL_Error Bad header foo:

/9 overtook /8

seen in vtest:

**   top   === server s1 -repeat 5 {
**   s1    Starting server
---- s1    Server listen address (127.0.0.1 58150) cannot be resolved: bind(2)

NB: I am not sure about this attempt

false negatives reported by vtest:

**   top   === logexpect l1 -wait
**   l1    Waiting for logexp
**** l1    match|       1005 VCL_use         c vcl1
***  l1    expecting| expect 0 = ReqURL struct
**** l1    err  |       1005 ReqURL          c /encode
---- l1    bad| expectation failed

fixes #3485

they are revealed by vbe_dir_event() on a warm event

Fixes #3358

VBP_Control() asserts that, when the vcl is warm, probes are scheduled
to run (that is, exist on the probe scheduling binheap) and not so
when the VCL is cold. This is correct because any VCL events are
guaranteed to be serialized by mgt.

vbp_thread(), however, momentarily left probes removed from the
binheap while scheduling a probe not holding vbp_mtx, which left a
window for VBP_Control() to find an active probe not on the binheap.

Both vbp_thread() and vbp_task() re-schedule the probe at hand. The
former in case scheduling the task fails, and the latter to reschedule
it at the right interval relative to the probe having finished.

We now re-schedule the probe in vbp_thread() before adding a task to
run it, which does not change anything about the above, and, in
particular, keeps vbp_mtx free while adding the probe task.

Yet it closes the race and thus

fixes #3362

survived varnishtest -t 90 -n 10000 -j 200 -i tests/v00003.vtc

it does not need many worker threads and runs for >30s. This helps being
able to run this test with more concurrency to test #3362

... thinks this statement is confusing.

Ref: 15f94d33

VRT_new_backend_clustered() is the only caller of VBP_Insert().

There, VBP_Update_Backend() needs to be called after the director is
created in order to update the director status for a cold VCL.

For a warm VCL, VBP_Update_Backend() is called via
VRT_AddDirector() -> VDI_Event() -> vbe_dir_event() -> VBP_Control()

Thus, the additonal call before the director is added to the backend,
does not do anything but update the poll bits.

Somehow related to #3362

We don't need to assert the integrity of the VSB after every single
byte, it can become very expensive depending on the workload.

Ref 001485e6

Going back to lowercase, and aligning code blocks to 4 spaces to match
the rest of the code snippets.

Ref #3470