As per spec a client can only send a HEADERS frame to cause a stream to
transition from the "idle" state to "open". A PRIORITY frame can be sent to an
"idle" stream, but it will remain in that state.

rfc7540,l,916,940
https://tools.ietf.org/html/rfc7540#section-5.1

To open a stream the command

txreq -nostrend

can be used. The -nostrend option will ensure that the stream won't transition
to a "half-closed" state.

be694992 unnecessarily changed the
values of most vsl tag enums and thus introduced an incompatibility
with logs written with previous code.

Fixes #2790

Fixes	#2788

This reverts commit 4e7e3499.

If the worker pool is configured too small, it can deadlock.

Recovering from this would require a lot of complicated code, to
discover queued but unscheduled tasks which can be cancelled
(because the client went away or otherwise) and code to do the
cancelling etc. etc.

But fundamentally either people configured their pools wrong, in
which case we want them to notice, or they are under DoS, in which
case recovering gracefully is unlikely be a major improvement over
a restart.

Instead we implement a per-pool watchdog and kill the child process
if nothing has been dequeued for too long.

Default value 10 seconds, open to discussion.

Band-aid for:	#2418

Test-case by:	@Dridi

(Same as we do in H1)

Fixes #2589

Spotted by:	Willy Tarreau <w@1wt.eu>

Fixes #2787

my apologies: as long as we pass around a struct wrk, some other
function could use the wrk->stats - in other words, the fact that
the ban stats are decoupled from the wrk stats does not make the
latter any less relevant.

This reverts commit 527f1bd0.

Checking and preparing our worker struct does not need to happen
under the lock.

Over time, I have repeatedly stared at this code again and again
wondering if (and why) our cv signaling is correct, just to end up
with the same insight each time (but first overlooking #2719)

Being fully aware that we do not want to plaster our code with
outdated comments, I hope this explanation is warranted to save myself
(and others, hopefully) from wasting precious life time on reiterating
over the same question.

Fixes: #2782

Take 2. Let's see if this time sticks.

Restructured so that:

* 'Upgrading' is limited to work that has to be done to upgrade from
  a current deployment to the new version.

* 'Changes' is a comprehensive, user-level description of changes and
  new features.

This adds -Wno-implicit-fallthrough for libvgz to satisfy gcc7.

The -Wno-unknown-warning-option is there to satisfy older gcc/clang that
don't recognize -Wno-implicit-fallthrough.