Move icons out of the vault file to a separate folder

[alexbakker]

Today, we store everything in the vault file, even icons. This decision was made early on in the project to get quick and easy support for icons, but as more people are starting to use Aegis, this technical debt is starting to show issues all over. It's a source of performance issues and crashes. The most recent example of this is #130.

Therefore, I propose to move icons out of the vault file, into a separate folder. This would allow us to load the vault separately from the icons, improving performance and stability, with the cost of some added complexity to the code. All icons would be stored in the icons folder, with random UUID's as filenames. I think we should still encrypt them, so entries in the vault also need a reference to their icon, along with some parameters for decryption. It'd look like this:

"icon": {
	"uuid": "01234567-89ab-cdef-0123-456789abcdef",
	"mime": "image/jpeg",
	"params": {
		"nonce": "0123456789abcdef01234567",
		"tag": "0123456789abcdef0123456789abcdef"
	}
}

As icons are no longer included in the vault, they would also not be included in exports. We'd have to use some kind of container format to export the vault along with all of the icons, like zip or tar. Java seems to have a decent API to create zip files, so we might as well use that, but I'd rather have something that doesn't do compression as we won't benefit much from that anyway.

The only security-related consequence is that someone with access to the vault would be able to determine the (minimum) amount of entries the vault contains. I think that's acceptable.

[chiraag-nataraj]

The one thing I worry about with a container format is resilience to corruption. With the current backup methods, the files are plain-text. While that's not too useful with the encrypted backup, it's a lifesaver with the unencrypted backup, since users can always recover something from even a corrupt backup.

What if the icons were merged together with the vault data at export time? It might increase the time for an export, but it would also ensure the current resilience to corruption and data loss.

[alexbakker]

We don't have plans to do this anymore. #509 will be implemented first, and we'll see if this is still necessary afterwards. Closing for now.