perf: optimize hash naming for MySQL storage

[ankush]

InnoDB is "index organized"* and the primary key is that index. So random names can send rows all over the place.

Typically documents created closer in time should live closer on mysql pages too.

Test: I created a DocType with 300 documents and each containing 1000 child table rows.

operation	before	after	difference
read a single document w/ 1000 child table rows; MySQL pages read	885	8	100x reduction
create a new hash name (microseconds)	1.65	3.94	2.3x increase

Pages read numbers are mostly meaningless as they depend on # of rows read. The general idea is previously number of pages read was proportional to the number of rows read because of random distribution of data. The proportionality factor being how many rows can fit in single 16KB page.

Notes:

• This data is from bufferpool stats, not 100% accurate.
• mariadb was restarted everytime before executing query. So data shouldn't be in pool by default.
• Default page size in mariadb is 16kb, you need A LOT of data to trigger this. Make sure you hit at least >100mb table size before testing anything.

TODO:

• verify test results with more reliable setup.
• any side effects?

* - https://15445.courses.cs.cmu.edu/fall2023/slides/04-storage2.pdf (page 25)

[ankush]

Merging this for now, it's slightly better than random inserts. This PR helps up until ~1gb of table size by some rough math. (16 (0 to f) ^ 3 (hex from timestamp) * 16kb page size)

ULID is best long term fix.