Add support for storing blobs on shared storage

[kriszyp]

There could potentially be benefits from being able to store blobs on a shared storage device that is accessible to multiple nodes.

[cb1kenobi]

In order to efficiently store files on a shared storage device, we need to adopt a common filename for blob files. Per-node auto-incrementing numbers won't work. Twitter/X has created an efficient timestamp-based unique identifier called a "Snowflake ID" (https://en.wikipedia.org/wiki/Snowflake_ID). Snowflake IDs use 63-bits and can be stored in a uint64_t or int64_t. In JavaScript, we would need to use BigInt.

Files should be stored in folders that use the last 8 or 12 bytes for the storage locations as to not put too many files in a single directory. The path would look like {tenant}/{AA}/{BB}/{full-uuid} where {AA} and {BB} are taken from the last 8-12 bytes of the ID.

Files would be stored on at least 2 storage nodes per region, each with attached block storage. Each storage node would deploy GlusterFS (open source, actively maintained, highly available). Each Harper node mounts all GlusterFS storage nodes as a single mountpoint using the glusterfs-client. When Harper writes a file, it writes to all storage nodes simultaneously. When a storage node goes down and comes back up, GlusterFS will resync/repair the files. One potential issue with only 2 nodes is split brain where the storage nodes lose communication with each other and become out of sync. Adding a 3rd lightweight "arbiter" node to store metadata to tiebreak conflicts (think RAID5 parity drive).

Since the GlusterFS mount appears as a normal directory to Harper, it's no different than storing locally like we do now and doesn't impact embedded scenarios.