feat(rpc): Introduce the new method generate_epochs in the IntegrationTest module

[EthanYuan]

What problem does this PR solve?

Problem Summary:

In the context of CKB applications, many contracts are closely tied to epoch processes, including "DAO" script, "cheque" script, and others. During the development process, facilitating the acceleration of epochs becomes essential.

Before this PR, there were two methods:

1. relied on miners rapidly producing blocks
2. required multiple calls to the CKB RPC generate_block

Clearly, the latter is more suitable for integration testing (without requiring a miner). However, using generate_block poses two issues. Firstly, it requires the calling side to calculate and determine the number of times generate_block should be called based on the desired epochs to fast-forward. Secondly, if called too quickly, generate_block may produce duplicate block hashes (indicating that no new blocks were generated), necessitating deduplication on the calling side.

The newly designed RPC generate_epochs introduces a parameter called num_epochs. Upon successful execution, it will return the current epoch target (in the form of EpochNumberWithFraction), significantly simplifying integration testing for applications like "DAO".

What is changed and how it works?

What's Changed:

add rpc:

#[rpc(name = "generate_epochs")]
fn generate_epochs(&self, num_epochs: EpochNumberWithFraction) -> Result<EpochNumberWithFraction>;

Check List

Tests

• Unit test
• Manual test (add detailed scripts or steps below)
  • dao-related tests
• No code ci-runs-only: [ quick_checks,linters ]

Release note

Title Only: Include only the PR title in the release note.

[15168316096]

The actual request response does not have "error": null

ckb@test-02:~/xueyl/ckb/ckb/generate_epochs/specs$ curl --location 'http://127.0.0.1:8202' \
> --header 'Content-Type: application/json' \
> --data '{
> "id": 42,
> "jsonrpc": "2.0",
> "method": "generate_epochs",
> "params": ["0x7080000000002"]
> }'
{"jsonrpc":"2.0","result":"0xa0000000004","id":42}

[EthanYuan]

It seems that similar issues exist in other RPC method examples, and we can consider removing them together.

[15168316096]

If the request growth epoch is too large, the waiting time will be too long. The more logs generated, the higher the CPU load. Let’s see if we can optimize the CPU usage through asynchronous means.

ckb@test-02:~/xueyl/ckb/ckb/generate_epochs/specs$ curl --location 'http://127.0.0.1:8202/' --header 'Content-Type: application/json' --data '{
  "id": 42,
  "jsonrpc": "2.0",
  "method": "generate_epochs",
  "params": ["0xFFFFFFFFFFFFFFFF"]
}'

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2624591 ckb 20 0 1811504 782352 60596 S 360.8 2.4 47:56.19 ckb

[EthanYuan]

This feature is only enabled in the development chain, and it doesn't make any sense for developers to set too large a value. It is a low priority to optimize for such usage scenarios.