refine/improve the design of worker and simple worker implementation

[sio4]

The current design and implementation of Worker and Simple worker are somewhat ambiguous and they need to be redefined. The points of consideration could be:

• Definition of Worker and its components including functions
• How to make them more reliable (when starting, stopping, and while running)
• Workflow (both automatic parts and manual parts)

TODO

• How to check if the worker is ready to work
  • When the worker should be initialized?
  • How to check if the worker is ready?
  • and purpose of the context
• Define the purpose of Start(context) clearly
• Consider timeout and/or cancellation for background jobs
• Consider if the already-submitted jobs to be performed even if the worker canceled before they are executed

Context

• Panic in Simpleworker #2241 (but not directly related)
• Bug: Buffalo app is never gracefully shut down #2198
• fixed racing condition of the simple worker #2266

See Also

• feature: Add cron-style periodic worker support #2351

[acaloiaro]

@sio4 I've been working on something that might be relevant to this issue: https://github.com/acaloiaro/neoq

It's still immature, but progressing nicely. With its current MemBackend and PgBackend implementations, I can see it being a reasonable replacement for SimpleWorker and gocraft/work. More out-of-the-box backends will be in the works for data stores like Redis, SQS, RabbitMQ, etc.