Refactor message thread to use concurrent API request handling

[redshiftzero]

The message thread added in #99 was developed prior to the ability to run API calls in multiple threads in #91, and we can simplify the message downloading code by reusing the functionality added in #91. See @ntoll's review comment in #99 for more context on this.

[redshiftzero]

@joshuathayer raised a good point just now in gitter which is that we want to prevent starting the download of the same file more than once, so, we probably only want one download thread occurring at one time.

Doing something like adding a function to the sync logic that starts up an API thread to download/decrypt each message that is not downloaded may result in some duplicate downloads if a user tries to refresh before all downloads have finished.

We could introduce logic to ensure this is not the case, but that might actually increase complexity... I'm curious on your thoughts on this @ntoll

[eloquence]

Moved off current sprint per @redshiftzero - deferred to beta.

[redshiftzero]

message_thread is gone, closing