Add promises

[sualko]

I did just some quick tests, but I think it needs some more exhaustive ones.

[arlolra]

First things first, looks like we need to get the test suite running on Travis again.

[arlolra]

The grunt fix here was merged as 25bfc26.

[arlolra]

In general, you probably want to reject promises in the those functions, rather than call notify.

Also, this could use a rebase.

[arlolra]

This promise is never rejected or fulfilled, similarly all the cases below where the functions return early.

[sualko]

This was by purpose, to resolve a Promise only if there were some data to send. But yes in this case sendQueryMsg should return a promise and also notify should return an rejected promise. Will update the pr accordingly.

[arlolra]

Probably want to reject here.

[sualko]

Throwing an exception is the same as rejecting.

[arlolra]

return promise.reject(msg.msg), no?

[sualko]

I just encountered that I have to add promises to a lot more functions, like doAKE and so on. This will take a lot more time and I have to think about a smart polyfill solution.

[arlolra]

Ok, there may be some hints in #75 which promisifies some portion of the code.

I did just some quick tests, but I think it needs some more exhaustive ones.

Yes, adding to the test suite would be beneficial.

[jcbrand]

@sualko Concerning a polyfill, you can try es6-promise.

[sualko]

Before I continue, we have to decide when receiveMsg, sendMsg and endOtr should resolve. In my opinion promises should not replace the io handler, because e.g. during the AKE there are multiple messages exchanged and a promise can resolved only once. We also have to decide if a notification (this.notify) is the same as an error which leads to rejection. For me it's not and therefore I believe we should not resolve or reject the promise.

The aim of promises in this case (at least for me) is to get a relation between a plaintext and encrypted message, which is ensured in the current pr.