• Depends on Shipper doesn't support infinite retry / robust failure handling #262

Add tests to confirm that the shipper does not lose data when retries are necessary or the shipper is restarted. The goal is to ensure we continue to satisfy Filebeat's "at least once" delivery guarantee: https://www.elastic.co/guide/en/beats/filebeat/current/how-filebeat-works.html#at-least-once-delivery

• A test should exists to prove that data published to the shipper is asynchronously acknowledged when:
• Data is successfully written to the output system using any retry policy.
• Data fails to write and then succeeds after an initial error when using the infinite or max retry policies.
• Data fails to write and then is dropped when using a max retry policy.
• A test should exist to prove that end to end acknowledgement behaves correctly when the shipper is restarted during publishing. Specifically, acknowledgement or queue identifiers must not not reused between restarts of the process to avoid acknowledgement collisions.