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.

And avoid the indentation of characters in vcc_assign_expr().

Fixes #3079
Closes #3100

At this point we should probably consider renaming the arithmetic table
to something also more general.

Refs #3100

It uses a similar trick as VCC expressions to find where the symbol name
belongs.

Refs #3100

First, gather everything needed, then generate the C code. This avoids a
bit of code duplication and makes the error handling more natural, right
after the attempt at generating a matching expression.

Refs #3100

    Avoid VSB_printf for static strings

    Done with the following semantic patch for Coccinelle:

        @@
        expression vsb, fmt;
        @@

        - VSB_printf(vsb, fmt);
        + VSB_cat(vsb, fmt);

    This patch is available in the Varnish source tree.

    vtc_haproxy: enable mcli with a separate flag from worker mode

    Support for the master cli in worker mode was added with commit 86e65f1
    using the same flag as worker mode (-W). This is a problem with haproxy
    1.8 because it has worker mode but no mcli. This patch adds -S to enable
    mcli for haproxy in a vtc.

and:

    The two patches in attachment fix a bug in the haproxy CLI handling and add
    the support for the haproxy master CLI in VTest. Could you merge them? Thanks
    You can also find in attachment a vtc file which use this new feature.

    Submitted by:   William Lallemand <wlallemand@haproxy.com>

enum gethdr_e and VCL_HTTP have a 1:1 relation except for HDR_OBJ which
does not have a corresponding VCL_HTTP pointer.

As I am about to use a "reverse VRT_selecthttp()" to get from VCL_HTTP
to enum gethdr_e, I would want to guard against accidental introduction
of a regression.

Ref #3145 / 287dc4a6

Ref #3145 / 287dc4a6

Fixes typo in storage backends guide.

There's only one place where a symbol may be assigned the SYM_OBJECT
kind and it is ensured that the JSON descriptor is found and added to
the symbol.