While investigating #103 I re-read the process() implementation and how we conjoin promises + callbacks for job handlers and it got me thinking a little bit - I want to get away from the callback API, and it's also just sort of that time where we get fully onboard the promises + async/await train.

Plan:

• Use, treat, and support async/await as a first-class thing
• Stop supporting/using callbacks for anything
• Migrate Redis client to ioredis
• No longer require promise-callbacks dependency
• Support only Node 8.x+ for native async/await

Pros:

• Remove promise-callbacks dependency (and save a little bit of corresponding overhead)
• Simplify some dual-pronged code paths and error handling scenarios
• Improve overall codebase readability
• Better utilize native Promise and async/await performance improvements (which have been significant in the last year)

Cons:

• Will be backwards-incompatible, with no more callback support
  • Should not require code changes for users already using promise-based handler functions
  • Users requiring the callback API can use 1.x
• Will not support old Node versions
  • Node 4 is EOL, Node 6 is old, everyone who will upgrade bee-queue to 2.0 will be on Node 8+

In general, asynchronous control flow stuff is easy to get wrong and having one API instead of two reduces the surface area for potential problems (like the confusion in #103). I also think the codebase could get a lot more readable with some async await mixed in and I refuse to introduce a build step.

I don't think 2.0 will change how bee-queue works at a Redis level - just improving the JavaScript interface.

So, seeking feedback:

1. How does this sound?
2. Are there any other things that should be thought about for 2.0, since it'll be a major version?

We can add other potentially-minor-version things to the milestone too, but let's especially make sure to think about changes we might want that could only go into major versions.

/cc @skeggse @bradvogel