backend: Pluggable blob storage interface supporting attachment documents

[LINKIWI]

What type of PR is this?

(REQUIRED)

• feature

What this PR does / why we need it:

(REQUIRED)

Currently, Homebox attachment storage works by reading and writing files on the local filesystem, rooted with the "storage data" directory. The business logic for the mechanics of this attachment file R/W is intertwined inside the attachment and document services, and the attachment API handlers.

This PR proposes decoupling attachment storage from the core business logic behind a generic "blob storage" interface. The underlying motivation of this work is to enable future support for other attachment storage backends--for example, S3, or private object storage, etc. This patch is structured such that someone could easily add a new blobstore implementation based on any storage backend of their choosing.

To accomplish this, this change introduces a new blobstore package with only one implementation, backed by the local filesystem, which is behaviorally equivalent to the current attachment storage behavior. Attachment storage works identically both with and without this PR, and this PR is also fully backwards compatible.

While I was here, I also used this as an opportunity to fix data directory relocation resiliency. See the inline commentary for details. This required a change to the metadata (DB) storage convention.

Which issue(s) this PR fixes:

(REQUIRED)

Special notes for your reviewer:

(fill-in or delete this section)

Testing

(fill-in or delete this section)

• Manual test: ensured that previously uploaded attachments continue to be served correctly, and also verified that newly uploaded attachments are surfaced and served correctly.
• As a proof of concept, I implemented an in-memory blob store and verified that Homebox is capable of using this storage backend transparently. In-memory attachment storage is obviously not useful to real users, so its implementation is not included in this PR.
• Unit tests updated and passing.

Release Notes

(REQUIRED)

NONE

[LINKIWI]

Hm:

12:40AM FTL backend/app/api/main.go:117 > failed creating schema resources error="sqlite: check foreign_keys pragma: reading schema information unable to open database file: out of memory (14)" driver=sqlite url=.data/homebox.db?_pragma=busy_timeout=1000&_pragma=journal_mode=WAL&_fk=1

I don't think this PR should cause excessive memory usage at startup time. At least I cannot repro.

[JeremyBolster]

FYI that error is from not being able to write the sqlite DB to the data directory, not an actual OOM. You get the same error if you try and change the user during docker run.