Ent Faktory Batches Guarantees

[rustworthy]

The Rust bindings for Ent Faktory features are now being added in faktory-rs , namely ergonomic access to batches and trackable jobs is now being worked on.

The wiki is very helpful plus the macos binary you bundle with each release - super important for testing! Also the Go client is an authoritative source of knowledge, especially when in doubt :)

As advised by Mike Perham in the recent email conversation, opening an issue with some findings (for Faktory 1.8.0, i.e. latest):

• we managed to open an already committed batch "from outside" and the server will accept both extra jobs and event nested batches instead of errorring back, while the docs will say this is not possible;
• we also managed to add more jobs to the batch for which the Faktory server had already queued the callback;

To demonstrate, a PR with an integration test and an Ent Faktory CI workflow will be added.

---

As a side-note: The tests we've got confirm that the following guarantees mentioned in the Ent Faktory wiki will definitely hold:

• callbacks will fire immediately after the jobs of this batch have been executed, provided the batch has been committed;
• callbacks will fire immediately for an empty batch, provided it has been committed;
• 'complete' callback will always be queued first;

[mperham]

Thanks for the great issue and PR!

• [x] we managed to open an already committed batch "from outside" and the server will accept both extra jobs and event nested batches instead of errorring back, while the docs will say this is not possible;
• [ ] we also managed to add more jobs to the batch for which the Faktory server had already queued the callback;

I don't think I can do much about the first one as I don't want to get into policing race conditions. The behavior will be undefined.

For the second item, I think I can use the callback state to raise an error if reopening the batch and the callback state is not blank.