Fix behaviour when the destination file is deleted

[purbon]

Context

As commented out in #20, if during the time LS is running the destination file is deleted by another agent in the machine, the plugin takes the event without any kind of feedback. This makes the plugin behaviour awkward and confusing, including data loss.

Reason

This happen because the plugin caches the file objects without doing any maintenance in case the file got deleted. There is a check for something similar at close_stale_files function, but this might not make it on time.

Fix

Add a new variable (create_if_deleted) to control the behaviour and make the open function react to it. Also include an option to forward events to the failure file in case this new variable is set to false. This enhancements make feedback always there, either by adding the files again to the destination file or using the failure file, there is also logging added.

Fixes #20

[jordansissel]

This introduces up to 2 File.stat calls per event sent to this output where previously there were zero File.stat calls per event.

I wonder about the performance implications of this.

Maybe we should only bother checking if the file is deleted if @create_if_deleted is true, that way the performance penalty is isolated to those wishing to use this 'create-if-deleted' behavior?

[purbon]

this is a fair concern, however I added another "feature" here, if the file is deleted but @create_if_deleted is false, it appends the data to the failure file, like this there is no chance stuff is "lost". What do you think?

[jordansissel]

Tests pass. Code LGTM. One comment about the performance impact of doing 2 stat syscalls per event.

[purbon]

Amended my last commit, because this will make the situation where the error file is deleted not being recreated again, I think this might be a bug. Lets release the plugin like this and improve the situation if required.