Ref #2575

Under stress we might otherwise check n_objectcore before it gets a
chance to decrease completely.

Spotted via vtest.

This test was failing before silently: It seems these vtest machines do
not resolve localhost to the address passed as the localhost define to
vtest, so use the latter in order to stabilize.

I should have included the netnotation right away

Every time I read this code I fail to remember which symbol is which, so
from now on the instance symbol will be called isym, the object symbol
osym and the method symbols msym.

They fit within 80 columns.

Instead, the comma is emitted when there is indeed an extra argument.

This change was initially submitted in #3147 and is needed when the
extra argument may vary for a given symbol. More specifically, when
a method symbol may be shared by several instance symbols, it becomes
really difficult to find a spot where that extra comma might be added.

Removing it from the extra argument itself makes this easier once we
reach the point where method symbols are unique (per object) instead
of repeated (per instance).

At the end of the VGC we output the contents of the symbol table inside
a C comment. It might look like this:

    /*
     * Symbol Table
     *
     * reserved  VOID       41 41 acl
     * reserved  VOID       41 41 backend
     * action    VOID       40 41 ban
     * var       HTTP        0 99 bereq
     * var       BACKEND     0 99 bereq.backend
     * [...]
     */

All columns are currently aligned because we know all the native VCL
types and only the last column with the symbol names has unpredictable
and arbitrary entries lengths.

However, considering the following snippet:

    new fb = directors.fallback();

The involved symbols will look like:

    object    VOID      41 41 directors.fallback
    instance  INSTANCE  41 41 fb
    func      VOID      40 41 fb.add_backend
    func      BACKEND   40 41 fb.backend
    func      VOID      40 41 fb.remove_backend

In the future VMOD objects will likely grow their own types and for the
same snippet we may have this instead:

    object    directors.fallback  41 41 directors.fallback
    method    VOID                40 41 directors.fallback.add_backend
    method    BACKEND             40 41 directors.fallback.backend
    method    VOID                40 41 directors.fallback.remove_backend
    instance  directors.fallback  41 41 fb

This change was initially submitted as part of #3147, but was considered
trivial and fast-track-able by PHK.

responses to varnishadm.

Part of fix for: #3148

It should currently result in 1:1 RST code, and might be output slightly
differently to accomodate a help screen, without changing the semantic
of the RST code.

This has the unfortunate effect of splitting a single switch statement
into two, however the second one being based on an enum should yield a
warning if in the future a new binding is added but not handled.

For example a binding involving the <h> key?

For starters the include table will be used for two things: handle key
presses in interactive mode and generate the "Key bindings" manual
section. The table is so far built to satisfy those two requirements.

It should then be repurposed for a help screen in interactive mode and
possibly refined to accommodate this third use case.

Refs #2990

They have the same effect in practice despite looking different, so the
simpler option is kept. Also considering vi key bindings <j> and <k>
documented in the previous commit, <g> and <G> would definitely have the
same meaning as <HOME> and <END> in this context.

And avoid magic ASCII numbers when we could use character literals
instead.

mgt_cli_askchild() as opposed to directly through mcf_askchild()),
a truncated CLI response is not a failure.

Fixes #3038

Refs 45af9764

I actually did consider this before, but thought we should keep it
because we are currently dicussing to add a CTX to vmod object
destructors. But this piece of code is unrelated and at any rate the
argument can be added back when we need it.

in short: @Dridi is right

VCC generates a call to VPI_vcl_select() before returning to the fsm. We
basically conducted half a rollback in VPI_vcl_slect and a rull rollback
in the fsm.

De-duplicate this dance and assert in the fsm that our request looks
rolled back.

... which is the vcl the topreq started on

It is unclear to me what the original intention was, but at any rate,
the privs are not vcl-specific and the vcl argument was not used.

The motivation for this change is the follow up commit
"cleanup implicit rollback for return(vcl(...))": For this commit, it
would be unclear which vcl to roll back with, but as it actually does
not matter, I think this change is warranted.

As the FSM will fail for this case, we should not run the code in the
first place.

Multiple calls to the synthetic() function result in the accumulation of
all body parts. The ability to set a [be]resp body accidentally resulted
in the same behavior.

In other words writing `set resp.body = "string";` in VCL behaves as if
`set resp.body += "string";` was written instead. This patch introduces
an enum to distinguish between the two desired actions and enables both
syntaxes without touching the behavior of the synthetic() function.