Feature/issue 783 unlimited attachment size

[sosnovsky]

This PR allows loading of attachments over 5mb and adds progress spinner for download process.

close#783

---

Tests(delete all except exactly one):

• Difficult to test (explain why) - it's mostly UI change

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[tomholub]

code looks good so far

[sosnovsky]

It'll be nice to have decrypt progress percentage in the future too, as it takes almost the same time as download for big files.

[sosnovsky]

@tomholub currently I have only #812 task assigned to me, can you please check on what tasks should I work after this one?

[tomholub]

It'll be nice to have decrypt progress percentage in the future too, as it takes almost the same time as download for big files.

Download is network bound and decryption is cpu bound. You could do both at the same time, and it should take half the time overall, if you do streaming decryption. #230 But it's not simple to do across the Swift/JS boundary. But it's possible.

[tomholub]

@tomholub currently I have only #812 task assigned to me, can you please check on what tasks should I work after this one?

will do

[sosnovsky]

It'll be nice to have decrypt progress percentage in the future too, as it takes almost the same time as download for big files.

Download is network bound and decryption is cpu bound. You could do both at the same time, and it should take half the time overall, if you do streaming decryption. #230 But it's not simple to do across the Swift/JS boundary. But it's possible.

Got it, it'll be a great addition for app's functionality and will make large emails loading much faster.

[tomholub]

I'd like you to debug/finalize #854 . How about merging sequence? I suppose it may be easier to merge the big one first and then rebase this onto that, but we could do it the other way around if you think it's easier. Up to you.

[sosnovsky]

I agree - it should be easier to merge #854 to master first, and then rebase it into this PR, as there is less changes here. I'll check #854 now

[tomholub]

Tested, looks great

[tomholub]

@sosnovsky good to merge once conflicts addressed 👍

[sosnovsky]

@tomholub I merged master changes to this branch - the only issue was with fetchMsg function, it didn't execute async code for fetching mail size. I fixed it by using async instead of Promise.
This fix also affected Imap class (to make it conform to updated MessageProvider protocol) - I updated fetchMsg function there too 763ac4b#diff-8012f2f1a5073946e65bdfc88fd17e2b9ddad872c955b7cf6adfd7a1621bf345R12

[tomholub]

👍

[tomholub]

A detail - I'd prefer formatting like:

processedMessage =tryawait serviceActor.fetchDecryptAndRenderMsg(
message: input.objMessage,
path: input.path,
progressHandler:{[weak self] state inself?.handleFetchProgress(state: state)})

Else all of the inputs have no space due to large indentation.

[sosnovsky]

Okay, I'll use such formatting in the next commits

[tomholub]

I like explicit returns for the clarity :-) but don't insist.