Moved bloom filter binary to Play flavor

[malmstein]

Task/Issue URL: https://app.asana.com/0/1157893581871903/1199944591737638

Description:
F-Droid has flagged https_mobile_v2_bloom.bin in their build system. We can't have an embedded binary as part of the apk we send them.

This means that, anyone installing the app from F-Droid won't get the initial Http to Https upgrade until the data is downloaded in the background.

Play Store users will still get the initial protection the binary brings.

To solve this, we are creating a separate HttpsDataPersister for the FDroid flavour, which will not store the upgrades embedded in the apk.

---

Internal references:

Software Engineering Expectations
Technical Design Template

[malmstein]

@subsymbolic can you take a look at this when you have the chance? Let me know if I'm missing something. Installing both variants has worked for me and all https upgrades happen as expected

[subsymbolic]

I like your approach here! I wonder if we could split the logic at a more relevant spot though to avoid duplicating code, as it would be easy for someone to update the main implementation and forget about the FDroid one. So rather than duplicating the HttpsDataPersister class which has a bunch of logic that we want in both flavors, could we create a new HttpsEmbeddedDataManager (or whatever name works) with just the persistEmbeddedData method and have that be the item that gets two flavor implementations?

Does that make sense?

[malmstein]

Oh that's actually a great idea @subsymbolic! Makes sense that the only difference is the embedding part, so I'll make that the variant between FDroid and Play.

[malmstein]

@subsymbolic I think this looks cleaner now, let me know what you think

[subsymbolic]

Great work @malmstein. I added a couple of log statement suggestions. No need to rereview when they're done, just merge when you're ready.