Description

Now actions in actpool will be persistent on disk. There are three main functionalities:

persistence: It will save an action when it's accepted by actpool, with configureable datacap
load-on-start: all persistent actions will be load at actpool start
reload periodically: actions dropped in memory will be attemped to reload into memory periodically

Based on #4362

Type of change

Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[] make test
[] fullsync
[] Other test (please specify)

Test Configuration:

Firmware version:
Hardware:
Toolchain:
SDK:

Checklist:

[] My code follows the style guidelines of this project
[] I have performed a self-review of my code
[] I have commented my code, particularly in hard-to-understand areas
[] I have made corresponding changes to the documentation
[] My changes generate no new warnings
[] I have added tests that prove my fix is effective or that my feature works
[] New and existing unit tests pass locally with my changes
[] Any dependent changes have been merged and published in downstream modules

Aug 15 '24 23:08 envestcc

as discussed, a general comment is we should only enable this for blob tx, b/c each tx is 128kB and each block can take only 2 blobs, leading to a potential backlog of such txs. For regular tx (size is ~100 bytes, and don't have limitation in each block), it is not needed to persist them locally. Because after a restart, the stored txs are all either already added to past blocks, or purged due to processing error (like wrong chainID), seems useless to me to persist these regular tx