UUID integration

[EfronC]

This is just a simple example of how to integrate UUID::Tiny to use for the hash table IDs. This example generates a Timestamp like we currently do, but generates an MD5 UUID from it, which is always 36 characters long, so we only need to update the KEYS string to TANK_????????-????-????-????-???????????? to make it compatible. This of course would require far more work, like an script to migrate all existent tanks to the new format, but is enough for the moment for demonstration purposes.

I didn't add any dependency to LRR install scripts, since I want to know first if this a good approach, and if UUID::Tiny is the right version to use, or we can choose a different one, so if you want to test this branch you would need to install manually the module in your environment, but the good news is that if everything works correctly, we can get rid of the ominous "Can't wait for 2038!" message 😸

[psilabs-dev]

Some points for discussion, personal opinions only.

Use v4 (hence the v4 recommendation i.e. using UUID Tiny). v1 is basically what we have (well almost). For security reasons: https://www.ntietz.com/blog/til-uses-for-the-different-uuid-versions/

If we do move forward with UUID, I wouldn't mind a PR that adds just the dependency to the cpanfile. Then stamps and registry could bring it in, these features would not be subject to deprecation burden.

Regarding timestamp2UUID deprecation, both would probably need support during the migration period, for the sake of clients. However, we can do a couple things:

• On startup, LRR can scan for timestamp IDs and convert them to UUID variants, of which the timestamp counterparts become references to. This means that when a client fetches a category by its timestamp ID, LRR resolves it internally to the UUID entity in DB and serves it back to the client.
• New entities will not be created with timestamps, only UUID, this will control the timestamp blast radius.
• OpenAPI would support both timestamp and UUID formats.

The remapping of timestamp2UUID would need to be transactional. If UUID variant is created but timestamp is not linked then we have duplicates. If timestamp isn't linked to UUID LRR may create another UUID variant, which is also a duplicate.

There are several other scenarios like locking/concurrency (we're writing on two tanks basically) or downgrades back to timestamp.

[EfronC]

Yes, the UUID was just the example in the docs that I integrated quickly to open this PR, but V4 is most surely the one we will go, since that one is probably better for uniqueness.

I don't think this will be integrated to Stamps, which is the reason I separated it into this PR. Stamps(Pendant from Difegue's comments about changes in the DB) currently uses the archive id in the name to link archives with stamps, and in the keys it uses timestamps for sorting and creation date, so no point in changing that to a UUID(Although I'll change the timestamp to real milliseconds, since I think I found a way to do it correctly).

About the migration from timestamps, on my personal opinion, I think the best way to integrate that would be to add a plugin to convert the TS keys to UUID ones, so that way instead of running a one time script on server upgrade to do this, or adding a piece of code that would do this on runtime, you could just run the plugin once, it will fix everything, and even if something fails later, and you need to restore a backup, you can run it again. The plugin could also do the reverse for the downgrade, although it would no return it to the original TS, but a new one.

[EfronC]

BUG: A potential bug to appear with this integration is that Archive depends on being the only Hash table with 40 chars key, due to us using $redis->keys('????????????????????????????????????????'); to fetch them, so if there is another 40 chars key table, they will be treated as archives wherever we use the previous function. Since UUID are 36 char long, then this will be a problem, for example, with categories, since SET_<UUID> is 40 char long.

[Difegue]

I initially thought stamps could remain on timestamps for now, but UUID is something we might want to bring in for the registry... although tbh I also did think registry storage could just rely on plugin IDs since that's also what's used for saving settings anyway.

I'd also be inclined to one-shot the migration, but at the same time I don't think we can avoid having to support both, just in case third-party clients are saving category IDs on their side.
(Tanks aren't really publically available yet so it's fine to breaking change that part.)

i might get crucified for this but 2038 technically isn't that big of a deal, timestamps within LRR for IDs are just used for unicity so frankly who cares if we end up with TANK_000003 at some point 🤷
(date_added and co might be more troublesome but they're basically always decoded from strings in JS or other client apps, who can handle cramming them into an unsigned 64bit value)