afsocket-grammar: split {source,dest}_afsocket

Instead of using an indirect rule for unix/inet sources destinations,
propagate them to the top-level, just like syslog (and the future
network source/destination)

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afsocket: get rid of the "flags" member for AFSocket{Source,Dest}Driver

This patch removes the ugly "flags" member and its complicated initialization
in constructors, rather the code now uses booleans which is easier
to follow.

Also separate constructors were added for the syslog() driver case, in
addition to tcp() and udp().

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afsocket: move the transport() option of the syslog driver into a separate rule in the grammar

In order to make it usable from the upcoming network() source destination,
dedicate a new rule to KW_TRANSPORT rules.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
network(): added grammar skeleton and plugin registration

This patch lays the foundation for the upcoming network source/destination.
It currently only introduces the rules in the grammar, registers the
network keyword and the network plugins.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
logproto-builtins: register the client side for "dgram"

We don't do anything special on the LogProto level when dgram client is
being used, however for the sake of symmetry and to make the logic
that determines which plugin to use, also register that, for the time being
it is equivalent to LogProtoTextClient.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
network(): added new network source and destination drivers

This patch implements both source and destination drivers called
"network()", which encapsulates the previous tcp() and udp() drivers. The
advantage of using network() over tcp/udp is that it separates the message
format from the transport being used.

The transport can be specified using the transport() parameter (akin to
syslog()), the newly introduced plugin support for pluggable transport
mechanisms become available this way.

The message format defaults to traditional BSD syslog, but can
completely be customized using the template() option.

Here's a sample network source:

source s_network {
	network(port(2000) transport(udp));
};

Destination:

destination d_network {
	network("hostname" port(2000) transport(framed));
};

As you can see it is possible to use the new-style RFC5425 framing with
whatever (e.g. BSD or custom template formatted) message contents.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
func_test: added tests for network() source

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afsocket: handle unknown transport errors during initialization

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
system-source: Use follow-freq(1) on FreeBSD prior to 9.1

FreeBSD prior to 9.1 does not have a kqueue-pollable /dev/klog, so
syslog-ng would fall back to using timers, except that follow-freq()
is explicitly set to zero, also diabling timer-based polling. This has
the effect of making syslog-ng not read from /dev/klog at all.

To work around the issue, on FreeBSD prior to 9.1, use follow-freq(1)
for /dev/klog when using the system() source.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
dbparser: Make the context length available to action conditions

It was quite unintuitive to determine if a previous message exists in
the corellation context as the basis of the decision whether an action
should be run or not. This patch implements a $(context-length)
template function that returns the number of messages within a
corellation context, and can be used in the condition of an action.

This way it is easy to determine if a context contains sufficient
amount of messages for the event to be complete and run a different
action if it is not, e.g. if 2 messages are needed for an event, this
should emit an event message if there are enough messages and an error
message if not.

 <actions>
  <action condition='"$(context-length)" >= "2"'>
   <message>
    <values>
     <value name="PROGRAM">event</value>
     <value name="MESSAGE">Hello event!</value>
    </values>
   </message>
  </action>
  <action condition='"$(context-length)" < "2"'>
   <message>
    <values>
     <value name="PROGRAM">error</value>
     <value name="MESSAGE">Hello error!</value>
    </values>
   </message>
  </action>
 </actions>

(Based on a patch from Balint Kovacs <blint@blint.hu>, and
suggestsions from Balazs Scheidler <bazsi@balabit.hu>)

Requested-by: Balint Kovacs <blint@blint.hu>
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
logreader: Error out when follow-freq is 0, and fd is not pollable

In case an FD is not pollable, but follow-freq is 0, error out,
instead of silently not doing anything.

This is accomplished by breaking out the if (self->pollable_state ==
0) branch out of the big if/else chain, and making it a mandatory step
in the end.

Signed-off-by: Viktor Juhasz <jviktor@balabit.hu>
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
reader/writer start-watches code simplification

Rearrange and simplify the pollable_state logic, so that it is easier
to follow.

Signed-off-by: Viktor Juhasz <jviktor@balabit.hu>
Signed-off-by: Gergely Nagy <algernon@balabit.hu>