Add event framework (Log Lossy Feed events)

[Qinusty]

This PR introduces an event framework for driving defined system events
through a sink interface. A logrus logging sink is implemented
initially for logging event locally but event could also be
dispatched to alternative metrics/logging mechanisms.

The initial event which is added for this is to log and
identify potential loss of data between polling intervals.
This lossy feed problem is detailed in issue #83 and whilst
this doesn't fix the problem, it can help to identify and monitor
occurrences of this issue within a long running production environment.

Lossy feed event checking and dispatch is added as a utility in the feeds package
and is implemented within the currently supported feeds which have the potential to be lossy
(crates, npm, pypi, rubygems).

[tom--pollard]

nit: extra space

[tom--pollard]

Could be nice to provide the available sink types here in the error message? However this does then open the question if we should be doing similar for all config options so that's potentially suited for a followup.

[Qinusty]

This would be easy to do now but would add an additional burden to adding sinks which could easily be missed. I think that adding documentation for the currently supported sinks/publishers/feeds etc is something that should be done for supporting user configuration. #97 is open to track this.

[tom--pollard]

Agreed

[tom--pollard]

Great! Until #97 is resolved it may be worth just adding a small snippet to the example config in the README as part of this PR, highlighting it optionally enabled (not blocking on this however).

[tom--pollard]

As this is essentially opening up a new data type that can be put 'on the wire', (including the scope to have pubsub sinks in a similar fashion to the existing package publishers) does it make sense to have a defined expectation on what constitutes an 'event'?.

The event introduced here exercises all of the methods provided by the interface (component, type, message) when generating the logrus output. Could DispatchEvent() potentially pass a struct (validated with a schema for expected fields, format etc as with packages) constructed from the interface methods to the event handlers AddEvent() instead of the event itself?

[Qinusty]

As this is essentially opening up a new data type that can be put 'on the wire', (including the scope to have pubsub sinks in a similar fashion to the existing package publishers) does it make sense to have a defined expectation on what constitutes an 'event'?.

I think that the definition of an event can remain quite flexible, the exact reasoning behind a new event can be discussed during the implementation and review of specific event additions. As for how verbose this becomes, we can review this at a later date but the sinks can dispatch events in a filterable manner e.g. to specific type topics for a kafka sink (for example).

The event introduced here exercises all of the methods provided by the interface (component, type, message) when generating the logrus output. Could DispatchEvent() potentially pass a struct (validated with a schema for expected fields, format etc as with packages) constructed from the interface methods to the event handlers AddEvent() instead of the event itself?

Yeah I think this might need some tweaking to have an easily method of encoding data for transmission. We might want some form of standardised event payload which the individual Event implementations can populate. The current method of having the sink switch based on the event type isn't very extendable for many sinks and many events.

[Qinusty]

Extending the event framework for event serialization for future sinks is being tracked as part of issue #96.

[tom--pollard]

Other than my open 'nit' comment this all looks good to me, taking into account the followup issues that have been generated. Feel free to resolve the README suggestion comment regardless.