core/trie: persist TrieJournal to journal file instead of kv database

[jingjunLi]

Description

This PR provides another way to persist TrieJournal by write it into a log file instead of a kv database.

Use --journalFile flag to enable/disable the journal file feature.

Rationale

Persisting TrieJournal to KV database will cause problems below

• Additional WAL and compaction overhead in pebble/leveldb
• Big kv (>= 2GB) not supported by pebbledb. (Size out of bounds when write kv >= 2GB)

Changes:

Data Format

Journal Version
Disk Root
Disk Layer
-- **Layer Length**
-- Root
-- State ID
-- Buffer Nodes
-- **Layer Checksum**
Diff Layer
-- **Layer Length**
-- Root
-- Block
-- Trie Nodes
-- Journal Accounts
-- **Layer Checksum**

Journal Path: geth/chaindata/ancient/state.journal
Checksum: SHA256

Testing

Function test

• Normal Scenario:
  • When starting up for the first time, if the journal does not exist, blocks are appended normally.
  • Upon receiving a kill -15 signal, the journal is persisted with a size consistent with the file.
  • After the normal startup, blocks are appended normally.

The loaded diff layer matches the persistence saved as described above.

• Abnormal Scenario: Manually truncate a portion of the snap file (geth/chaindata/ancient/state.journal) and restart.
  • When the number of blocks appended is less than 460,000 ("Rewound to block with state" number=0), the blockchain rewinds to block 0 and resumes appending blocks once completed.
  • When the number of blocks appended is greater than 460,000, the blockchain rewinds to a position slightly behind the head number, and resumes appending blocks once completed.
    

Performance test

Scenario: Using TestJournal, each layer has 4K and 8K account operations.

	WriteJournal	LoadJournal	Dirty State Size
New Journal WAL	6.149s	12.496s	1.19GiB
Old KVDB	6.341s	12.340s	1.21GiB
New Journal WAL	11.724s	20.525s	1.85GiB
Old KVDB	11.107s	19.415s	1.85GiB

Conclusion: The use of Journal WAL and storing trieJournalKey directly into kvdb results in nearly identical WAL write times during shutdown and WAL read/parsing times during startup.

[zzzckck]

The solution is ok for me, it would bring some advantages:
1.avoid the 2GB large KV limit of PebbleDB, as TrieJournal could > 2GB
2.avoid set large content into the PebbleDB, which would be deleted on restart, additional DBCompact cost. Log file is much more efficient.
I was a little bit concerned about the code intrusion, but I think the change is not too much and is acceptable.

It can be merged once there are >2 approval.

[RenRick]

LGTM

[fynnss]

LGTM

[RenRick]

LGTM