Refactor entity and transaction IDs to UUIDs

[maxweber]

One point in Ideas for DataScript 2 is:

UUIDs for entity IDs makes it easier to generate new IDs in distributed environment without consulting central authority.

With this PR dbval would use UUIDs for entity IDs.

The biggest motivator for me is to avoid the need to assign an external ID to each entity. In past we often made the mistake to share Datomic entity IDs with the outside world (via an API for example), while this is strictly discouraged. In Datomic and Datascript each transaction also receive its own entity ID. dbval uses colossal-squuid UUIDs for transaction entity IDs. They increase strictly monotonically, meaning:

A SQUUID generated later will always have a higher value, both lexicographically and in terms of the underlying bits, than one generated earlier.

With com.yetanalytics.squuid/uuid->time you can extract the timestamp that is encoded in the leading bits of the SQUUID:

(uuid->time #uuid "017de28f-5801-8fff-8fff-ffffffffffff")
;; => #inst "2021-12-22T14:33:04.769000000-00:00"

This timestamp can serve as :db/txInstant to capture when the transaction has been transacted. UUIDs for entity and transaction IDs would allow to entirely get rid of tempids. However, they are still supported by dbval for convenience and to assign data to the transaction entity:

(d/transact! conn
  [[:db/add "e1" :name "Alice"]

   ;; attach metadata to the transaction
   [:db/add :db/current-tx :tx/user-id 42]
   [:db/add :db/current-tx :tx/source :api]])

Another compelling option of using UUIDs is that dbval databases become mergeable, if they adhere to the same schema. Thereby you can solve the following challenge: if you have a separate database per customer it is no longer possible to run database queries to get statistics across your customer base. With dbval you can merge all customer databases into a big one to run these statistics queries.

One obvious downside of UUIDs is that they need twice as much storage in comparison to 64 bit integers.