Refactor input interactions and boundaries

[ph]

This issue is coming from a discussion between @urso, @kvch and @ph

---

Recently we have refactored the interface used by prospectors to input, but we should do a bit more refactoring on the usage of the inputs especially between the interaction with each other.

• Currently, we have the Docker and the Log input coupled.
• We will have the Syslog and the UDP/TCP input coupled.

We think that An input must not use another inputs, inputs should be isolated and mostly deal
with configuration. Instead, the TCP/UDP/Log should be refactored to be reusable components for the
inputs. They could become InputReader or InputStream, that defined in their package.

We could have the following:

• A UDP Server
• A TCP Server
• A FileWatcher for files/log

This change is necessary with the planning of adding more inputs to Filebeat and making sure the code stay testable and isolated.

This issue is created to discuss implementation details and interface required for this change.

[ruflin]

I wonder if Docker, Syslog should just become a module instead of being an input. This change would mean certain modules in FB can also contain golang code which is more similar to Metricbeat. We were discussing in the past to remove the code part from the metricbeat modules but I see also advantages of having optional code there.

[exekias]

You can use Syslog and Docker as inputs in modules, I think that's why it makes sense to keep them as inputs. Apache could be running on Docker, and you want to pipe that to the module

[ph]

I will move this a bit forward this is blocking me for the Syslog input, I will start with the UDP and refactor TCP once its merged.

[ph]

By moving this forward I will create a proposal PR, currently the UDP part of the UDP takes care of parsing the strings and create the beats event, we need to make it work with low level type, in this case byte array.

We could create a constructor with the following signature.

func NewTCP(config *Config, callback func([]byte)) {
//...
}

In the current context call will be just a wrapper for creating the beat.Event and sending that to the forwarder.

[ph]

TCP and UDP changes are now in, only thing missing if the filewatcher refactor.