Load and store embedded dataset

[CrisBarreiro]

Task/Issue URL: https://app.asana.com/0/1205008441501016/1208870183150417/f

Description

Load and store embedded dataset for malicious site protection

• Note: An upcoming PR will add the remaining logic for fetching data from network, as well as the feature to update an existing dataset rather than completely replace it, as we're doing now. This PR just adds the bare minimum, so we can integrate the blocking algorithm and verify the feature works as intented

Steps to test this PR

• Check app startup is executed normally, no ANRs are detected
• Filter for "Failed to fetch embedded" and check no such logs exist

UI changes

no UI changes

[CrisBarreiro]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Add blocking algorithm (isMalicious) #5376 : 2 dependent PRs (#5406 , #5416 )
• Load and store embedded dataset #5370 👈 (View in Graphite)
• Intercept requests and add skeleton for malicious site detection #5369
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cmonfortep]

Left some questions about the insert, if that's the expected behavior I'm good here.

[cmonfortep]

NIT: you can extract some logic here to a generic method since every method has a similar structure.

private inline fun loadAndParseEmbeddedData(@rawres file: Int): T? {
return try {
val data = loadEmbeddedData(file)
val adapter = moshi.adapter(T::class.java)
adapter.fromJson(String(data, Charsets.UTF_8))
} catch (e: Exception) {
Timber.e(e, "Failed to fetch embedded data for resource: $file")
null
}
}

[cmonfortep]

QQ about inserts here: This will insert but not replace right? so it's additive and will replace only if there's a conflict. But if no conflict, old data will still be present. Example: if we have A, B, C, D, and receive B, D, E ...DB state will be A, B, C, D, E. Shouldn't be the new state B, D, E?

[CrisBarreiro]

@cmonfortep, you're right. In a previous implementation revisions were a FK, so by removing them, we would remove filters and hash prefixes, but that's not the case anymore. I'll fix it