This reverts commit 2bc56a4b.

We already assert that sym is not null, and we certainly don't expect a
reserved symbol to have slipped through since we already attempted the
least specific symnbol lookup.

This is not a case where we expect to fail because of user input.

When a VCL_HEADER argument is a vmod return value, it could be

- NULL for an error condition
- from a different context

Also, we should not assert on HDR_OBJ in VRT_selecthttp() to
facilitate error handling in vmods.

Fixes #3623

VCC_SymbolGet() could fail, e,g, if the token is reserved

Ref cf396384

Add test-coverage of internal function sf_parse_int()

Only the special cases get special handling.

With sanitizers it becomes too easy to trigger a timeout because of the
debug.priv_perf() invocations.

Note for later, I'm planning to change the feature syntax to this:

    feature [!]<name> [<args>...]

This way we can use `feature !sanitizer` to express the same check.

A side effect is slightly more accurate error messages.

Closes #3555

This migrates the remaining candidates for vcc_Peek*() functions using a
coccinelle semantic patch. When vcc_PeekToken*() is used in an assignment
statement it's straightforward to patch. In an expression a careful
review is needed, that's why the generated code is meant not to compile
on purpose. That's how the pattern for vcc_PrintTokens() was noticed.

The same pattern occurred 3 times while reviewing potential usage for the
new vcc_PeekToken*() functions.

Without advancing to the next token, and leaving the door open to
synthetic tokens that would otherwise interfere with direct access.

This is as far declaring symbols goes, because we can still find
hard-coded prefixes in other places. Having them in the types could
actually help centralize them for good, but this is a minimal change
for the purpose of referencing global symbols before they are defined.

Refs #3555

Spotted by: @dridi

(analog of storage_malloc.c)

The buf_len field is only ever modified by the poll thread and should not
need to be guarded here. This will hopefully silence a coverity warning:

   CID 1485138:  Concurrent data access violations  (ATOMICITY)
   Using an unreliable value of "l" inside the second locked
   section. If the data that "l" depends on was changed by
   another thread, this use might be incorrect.

It might on the other hand complain even harder, I have an alternative
if that happens.

Unlike other threads we cancel in varnishtest there's 2 per tunnel and
they need coordination between each other. The spec thread remains as-is
and the poll thread now checks vtc_stop after each condwait.

With this I'm no longer able to reproduce a21's timeout.

Reverts d4cf677a

The assertion above wasn't enough apparently.

And make a note that we should avoid pthread_cancel(3) in the future.