avoid callback hell with chrome.sendMessage

[kkuehlz]

The Firefox sendMessage implementation is much more sane than Chrome's. Instead of using a callback when the listener returns, it instead returns a Promise. For chained messages (which we will need to do for context menu decryption), it keeps us from entering the depths of callback hell.

We can either pull in https://github.com/mozilla/webextension-polyfill that will polyfill the mozilla sendMessage for chrome, or we could write a wrapper around the chrome API.

[dkess]

What part of the code is this needed in? I can look into it

[kkuehlz]

@dkess We probably want to change it everywhere because it's a better design. I have a slight preference for just writing a wrapper method that returns a Promise (goes in utils/message.ts) and sticking with the Chrome API as opposed to using the polyfill library. Since we don't need anything else polyfilled, pulling in the dependency seems excessive.

Right now we haven't quite entered callback hell yet. I was having a lot of issues when implementing selection decryption. Context menu triggered in background -> tell content_script to spawn iframe (cb 1) -> send ciphertext to iframe (cb 2) -> enable buttons (cb 3). This design will also let us simplify message listeners, break them into smaller components, and encourage message chaining as opposed to mono-receivers.