BREAKING CHANGE: awaitable queues

[aearly]

Closes #1586

This changes the queue API a bit, allowing queue events to be awaited, as well as the results for an individual task. You can now do:

var q = async.q(async fn (task) { /* ... */ }, 10)

await q.push(task) // awaits until task has been processed
await Promise.all(q.push([1, 2, 3])) // awaits for all tasks to be processed

q.push(5) //set and forget, this won't reject if an error happens

await queue.drain() // probably the most useful thing to come out of this change

[megawac]

That's quite an interesting way of handling both promises and the current API. Is the promise based API useful for any of the events besides drain?

[aearly]

It's most useful for drain, but i can see utility coming from unsaturated, and making error reject. I'm also happy making the interface uniform for all the event-style methods.

[darksabrefr]

await q.push(task) is not safe for use for the moment because the promise returned by q.push never resolve nor reject if the queue worker throws an error. I understand that await q.push(task) cannot throw an error because of the backward compatibility of this method and its optional callback parameter (the push and forget feature). A q.asyncPush(task) method that reject its promise shouldn't be feasible ?

You can show the problem with this code (in node or browser without the require):

const async = require('async');
let pushResult;

(async () => {
	const q = async.queue(async (task) => {
		throw new Error('Bad thing');
	});

	try {
		pushResult = q.push({some: 'data'});
		await pushResult;
		console.log('Error not catched');
	} catch (e) {
		console.log('Error catched');
	}
})();

setTimeout(() => {
	console.log('exit');
	console.log(pushResult);
}, 1000);