Revert "Fetch messages from mailserver upon PN if db is unlocked. Par…

[yenda]

…t of #3451"

This reverts commit 40b3100.

fixes #7521

[ghost]

Pull Request Checklist

• Have you updated the documentation, if impacted (e.g. docs.status.im)?

[cammellos]

same here, not sure reverting should be our default strategy, it has definitely a time and place, but most of the times I think we should fix the issue if possible, if too hard/time consuming reverting should be considered.

[yenda]

@cammellos why is breaking an existing feature more acceptable than reverting one? Also what is hard about a revert? It only requires to reopen the original PR and patch it

[cammellos]

@yenda that's not what I am saying, breaking an existing feature is not acceptable nor more acceptable than reverting.
This is a different scenario: Given that a feature has been broken (unavoidable at this point), it's better in my view to fix then to revert (if easy enough), as I prefer to move forward rather than backward. There are of course exception (the code has just been merged, the fix is difficult and likely to introduce new bugs etc).

[yenda]

@cammellos I don't have a strong opinion about this, I also like to move forward rather than backward, but if we choose to have QA test nightlies only, we should have no hesitation to revert commits with identified bugs in the future. I fixed this one now anyway

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	39ddde1	#1	2019-02-19 16:49:52	~20 min	android-e2e	📦 apk
✔️	39ddde1	#1	2019-02-19 16:53:45	~24 min	android	📦 apk
✔️	39ddde1	#1	2019-02-19 16:54:56	~25 min	ios-e2e	📦 pkg
✔️	39ddde1	#1	2019-02-19 16:55:38	~26 min	ios	📦 ipa
✔️	39ddde1	#1	2019-02-19 16:56:05	~26 min	macos	📦 dmg
✔️	39ddde1	#1	2019-02-19 16:59:54	~30 min	windows	📦 exe
✔️	39ddde1	#1	2019-02-19 17:01:31	~32 min	linux	📦 App