fix: l1 handler message hash to txn hash mapping

[EgeCaner]

Due to a bug, only the first L1Handler transaction in a block was written to MsgHash to L2TxnHash mapping, resulting in consecutive ones to be missing, leading to to error in starknet_getMessageStatus.

Includes migration

[codecov]

Codecov Report

❌ Patch coverage is 71.64179% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.63%. Comparing base (08560cb) to head (436b125).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
migration/l1handlermapping/migrator.go	67.85%	20 Missing and 7 partials ⚠️
migration/l1handlermapping/ingestor.go	70.83%	4 Missing and 3 partials ⚠️
core/accessors.go	71.42%	1 Missing and 1 partial ⚠️
migration/l1handlermapping/committer.go	89.47%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3367      +/-   ##
==========================================
- Coverage   75.63%   75.63%   -0.01%     
==========================================
  Files         358      361       +3     
  Lines       33846    33979     +133     
==========================================
+ Hits        25601    25699      +98     
- Misses       6430     6446      +16     
- Partials     1815     1834      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[thiagodeev]

LGTM.

By generating a benchmark with cursor, it seems the approach with a buffered channel is at least 15% faster. It's a one-line change, WDYT about it?

[rodrodros]

How long does the migration take. Is it super quick, no need, but if not, what do you think of adding some logging to inform users. I leave it completely at your discretion.

Also, is this operation light enough to work under the 8gb of ram and 4 core minimum requirements of Juno? I think yes, but asking just to be safe. An intuitive answer is good enough in this case in my opinion – let's not put more time into this PR than strictly required

[EgeCaner]

Migration was taking ~1 min 15 sec in my machine, let me run it in environment similar to minimum requirements

[infrmtcs]

I think how long it takes also matters because we're writing everything in a single batch. If user kills the process in the middle, all progress will be lost, and user has to suffer the same cost of migrating them again.

[infrmtcs]

@EgeCaner Is it sepolia or mainnet?

[EgeCaner]

Im not sure if we should allow to cancel. In case of cancel and re-run we would do the all operations again, migration wont start from where it was cancelled. To be able to remain from where we left, we need to track additional state, by taking a look at the table we are writing L1MessageHash to L2 txn hash we cannot tell were we left?

[EgeCaner]

Is it sepolia or mainnet?

It was Sepolia

[EgeCaner]

I will add some logs as well, on Mainnet it will take lot more than on sepolia

[EgeCaner]

LGTM.

By generating a benchmark with cursor, it seems the approach with a buffered channel is at least 15% faster. It's a one-line change, WDYT about it?

I tried the buffered channel but it didnt provided meaningful or any visible difference, time spent on channel is dwarfed by the other heavy operations DB read/write