detect: add and use util func for alproto sets

doc: update for unix socket hostbits

flowvar: shrink flowvar type by using padded space

lua: support key/value flowvars in lua

flowvar: remove unused DETECT_VAR_TYPE_ALWAYS

doc: update unix socket

suricatasc: add/list/remove hostbit commands

Syntax:
    add-hostbit <ip> <bit name> <expire>
Example:
    add-hostbit 1.2.3.4 blacklist 3600

Syntax:
    remove-hostbit <ip> <bit name>
Example:
    remove-hostbit 1.2.3.4 blacklist

Syntax:
    list-hostbit <ip>
Example:
    list-hostbit 1.2.3.4

unix-socket: add/list/remove hostbit commands

add-hostbit adds a named hostbit with an expire time in seconds.
remove-hostbit removes hostbit by name.

add-hostbit, remove-hostbit return success or failure.

list-hostbit returns a json array of hostbits with their name and
expire time:

    {
        "message": {
            "count": 1,
            "hostbits":
                [{
                    "expire": 3222,
                    "name": "firefox-users"
                }]
        },
        "return": "OK"
    }

hostbits: add list API

pktvars: same name pktvars, key-value vars

outputs: vars log

EVE addition called 'vars' that logs pkt/flow vars for each packet/flow.

eve: log pktvars/flowvars/bits/ints

Optionally logs 'vars' into alerts

pcre: new way of specifying var names

Until now the way to specify a var name in pcre substring capture
into pkt and flow vars was to use the pcre named substring support:
e.g. /(?P<pkt_somename>.*)/

This had 2 drawbacks:

1. limitations of the name. The name could be max 32 chars, only have
   alphanumeric and the underscore characters. This imposed limitations
   that are not present in flowbits/ints.

2. we didn't actually use the named substrings in pcre through the
   API. We parsed the names separately. So putting the names in pcre
   would actually be wasteful.

This patch introduces a new way of mapping captures with names:

  pcre:"/(.*)/, pkt:somename";
  pcre:"/([A-z]+) ([0-9]+)/, pkt:somename,flow:anothername";

The order of the captures and the order of the names are mapped 1 on 1.
This method is no longer limited by the pcre API's naming limits. The
'flow:' and 'pkt:' prefixes indicate what the type of variable is. It's
mandatory to specify one.

The old method is still supported as well.

pkt-var: abuse flowvar postmatch logic for pktvars

Flowvars were already using a temporary store in the detect thread
ctx.

Use the same facility for pktvars. The reasons are:

1. packet is not always available, e.g. when running pcre on http
   buffers.

2. setting of vars should be done post match. Until now it was also
   possible that it is done on a partial match.

pkt-var: use id instead of name pointer

pcre: support multiple captures

Support up to 8 substring captures into pkt or flow vars.

detect-pcre: small cleanups

alert-debug: print flowvar/int names

alert-debug: print flowbit names from VarNameStore

var-names: expose outside of detect engine

Until now variable names, such as flowbit names, were local to a detect
engine. This made sense as they were only ever used in that context.

For the purpose of logging these names, this needs a different approach.
The loggers live outside of the detect engine. Also, in the case of
reloads and multi-tenancy, there are even multiple detect engines, so
it would be even more tricky to access them from the outside.

This patch brings a new approach. A any time, there is a single active
hash table mapping the variable names and their id's. For multiple
tenants the table is shared between tenants.

The table is set up in a 'staging' area, where locking makes sure that
multiple loading threads don't mess things up. Then when the preparing
of a detection engine is ready, but before the detect threads are made
aware of the new detect engine, the active varname hash is swapped with
the staging instance.

For this to work, all the mappings from the 'current' or active mapping
are added to the staging table.

After the threads have reloaded and the new detection engine is active,
the old table can be freed.

For multi tenancy things are similar. The staging area is used for
setting up until the new detection engines / tenants are applied to
the system.

This patch also changes the variable 'id'/'idx' field to uint32_t. Due
to data structure padding and alignment, this should have no practical
drawback while allowing for a lot more vars.

detect: use engine version instead of id

Use engine version based on global detect engine master. This is
incremented between reloads.

detect: ssh_software sticky buffer

detect: ssh_proto stickybuffer

detect: remove unused SIGMATCH_PAYLOAD flag

detect: remove unused state file flag

detect: small API cleanup

detect: move file hash common code

detect: unify FileMatch API with other calls

detect: remove DMATCH list

flow: remove unused Flow::de_state

detect: remove the AMATCH list

detect: remove AppLayerMatch API call

dce: dynamic lists

smb/dcerpc: use tx api

dcerpc: simplify common detect code

ftp: parser and ftpbounce update

Convert parser to TX API.

Convert ftpbounce keyword to use that.

detect: move lua smtp support to dynamic list

lua: convert lua output to be tx aware

detect: make ssh detection use dynamic list

ssh: remove single logger limit

ssh: convert app-layer parser to be tx aware

Like with SSL, there is only a single 'tx'.

lua: use tls_generic list for ssl/tls

detect ssl/tls: use dynamic lists

ssl/tls: clean up keywords

detect: convert old tls keywords to dynamic list

tls.store: convert to postmatch

tls.store: cleanup

app-layer-events: remove unused API options

detect: http_start sticky buffer

Matches on the start of a HTTP request or response.

Uses a buffer constructed from the request line and normalized request
headers, including the Cookie header.

Or for the response side, it uses the response line plus the
normalized response headers, including the Set-Cookie header.

Both buffers are terminated by an extra \r\n.

detect: add http_protocol sticky buffer

Matches on protocol field in HTTP.

http_header: convert to use common code

http_header: common detection code

http_header: remove old files

http_header: move all code into keyword files

detect: http_header_names sticky buffer keyword

A sticky buffer that allows content inspection on a contructed buffer
of HTTP header names. The buffer starts with \r\n, the names are
separated by \r\n and the end of the buffer contains an extra \r\n.

E.g. \r\nHost\r\nUser-Agent\r\n\r\n

The leading \r\n is to make sure one can match on a full name in all
cases.

detect: global registery for keyword thread data

Some keywords need a scratch space where they can do store the results
of expensive operations that remain valid for the time of a packets
journey through the detection engine.

An example is the reconstructed 'http_header' field, that is needed
in MPM, and then for each rule that manually inspects it. Storing this
data in the flow is a waste, and reconstructing multiple times on
demand as well.

This API allows for registering a keyword with an init and free function.

It it mean to be used an initialization time, when the keyword is
registered.

profiling: output all sort options for rules

Limit the default number of sids to 10.

profiling: honor limit in json rule output

profiling: fix keyword profiling

detect-engine-mpm: api cleanup

detect: detect engine registration cleanup

detect: cleanup built-in list id's

template: dynamic buffer

app-layer-events: dynamic list

files: use dynamic list

cip/enip: dynamic buffer

modbus: dynamic buffer

dnp3: dynamic buffers/lists

tls: dynamic buffers

dns: use dynamic buffers

detect-parse: content modifier cleanup

http_raw_uri: dynamic buffer

http_client_body: dynamic buffer

http_header / http_raw_header: dynamic buffers

http_stat_msg: dynamic buffer

http_stat_code: dynamic buffer

http_raw_host: dynamic buffer

http_host: dynamic buffer

http_cookie: dynamic buffer

http_user_agent: dynamic buffer

http_response_line: dynamic buffer

http_uri: dynamic buffer

Clean up tests

http_method: make list dynamic

file_data: dynamic buffer

http_request_line: dynamic buffer

detect: remove hardcoded sm_list logic from setup

Introduce utility functions to aid this.

detect: buffer type API

To replace the hardcoded SigMatch list id's, use this API to register
and query lists by name.

Also allow for registering descriptions and whether mpm is supported.

Registration is only allowed at startup.

detect: inspect engine setup cleanup

detect: dce test fixes and improvements

detect-csum: redo tests

detect: move init only Signature members to init_data

detect: shrink Signature::sm_arrays

Signature::sm_arrays now only contains 'built-in' lists, and so is
sized appropriately.

detect: reorganize id's in prep of dynamic lists

threshold: fix and redo tests

detect: improve memory handling & comments

detect: get rid of Signature::sm_lists

Instead use the lists in init_data during setup and the SigMatchData
arrays during runtime.

detect: use detect list passed to generic funcs

Until now the GenericList users used hardcoded list id's.

detect: pass SigMatchData to inspect functions

detect: template list in engine

detect: enip/cip list in engine