feat: improve node startup time

[drahnr]

Ref #1697

Motivation

The node startup is still rather long, partially because we load more data than actually required.

Changes

1. avoid loading the full BlockHeader and instead adds a column commitment ( crates/store/src/db/models/queries/block_headers.rs and crates/store/src/db/schema.rs )
2. adds BlockHeaderCommitment wrapper type, it's a start for avoiding more Word-type(les)s

Caveat

Folds all migrations into the initial one, since it cannot work with the current migration pattern and the changes 'd be too large for this PR, see #1704 for further discussions on that.

[drahnr]

we should find a better name for the table used for tracking code migrations, open to suggestions

[Mirko-von-Leipzig]

If I understand the setup here correctly, can we not massively simplify matters by assigning every migration an ordered integer index (which they already have implictly), and then force every migration to also have what you call a data migration? Then we don't have to play funny macro / DNS-like resolution of diesel migration to function look up games.

You end up with something like https://github.com/eqlabs/pathfinder/blob/cb5c42b005562fca59c2ef044e83aa1464d4f58f/crates/storage/src/schema.rs#L43-L94

[drahnr]

That is correct, the main motivation was to not spend too much time on the migration, but get to a functional minimal impl.

I am tempted to just carve it out and squash all migrations and punt on the migrations impl/feat/refactor, to get #1697 done.

[Mirko-von-Leipzig]

If you're happy to do that; maybe let's start with that -- migrations will need to be solid; so I expect a lot of bikeshedding even in just the design portion.

[drahnr]

A brief brain-dump of my current thinking #1704 it's similar to https://github.com/eqlabs/pathfinder/blob/cb5c42b005562fca59c2ef044e83aa1464d4f58f/crates/storage/src/schema.rs#L43-L94 with a bit more automation and keeping the date-as-version approach.