feat(btc|service): support internal query data caching in TxBuilder.payFee()

[ShookLyngs]

Changes

• Support query data caching internally in TxBuilder/DataSource, preventing query from the service too often
• Add type changes in the feat(service): add no_cache params to btc/rgbpp service api #181 to the service readme

Query data cache

Previously, when collecting inputs for paying fees, the BtcAssetsApi.getBtcUtxos() API and the BtcAssetsApi.getRgbppAssetsByBtcUtxo() API were queried multiple times. In this PR, a DataCache is added to prevent querying the same API with the same params too often.

Reference: #173 (comment)

Test

• @Dawn-githup

[ShookLyngs]

Here are some suggestions from @ahonn:

• No need to expose the noUtxosCache option in the TxBuilder.payFee() (to the users)
• The noUtxosCache option can be set to true by default when paying fee

[Dawn-githup]

https://pudge.explorer.nervos.org/xudt/0xdc50aa08391b9f7831e08a70884e1094dae8984412e52a8c8371ca3bbccc44f5

Verify that there are 36 cells：

• develop branch build transaction time:：

• This branch builds transaction time:

[duanyytop]

https://pudge.explorer.nervos.org/xudt/0xdc50aa08391b9f7831e08a70884e1094dae8984412e52a8c8371ca3bbccc44f5

Verify that there are 36 cells：

• develop branch build transaction time:：

* This branch builds transaction time:

Is there still room for improvement in the time cost reduction by the cache? Or is this test case not typical enough?

[ShookLyngs]

Just renamed the cache-related options to make them look clearer:

• noUtxosCache -> noAssetsApiCache
• cacheKey -> internalCacheKey

[ShookLyngs]

Is there still room for improvement in the time cost reduction by the cache? Or is this test case not typical enough?

The problem can be broken down into two parts:

1. The test case is using the sendRgbppUtxos() API for testing, which is indeed not typical enough because this PR aims to improve the construction time for transactions that collect a large amount of inputs during the fee-paying process.
2. The sendRgbppUtxos() API can be optimized individually, as it contains time-costly syntax like for (...) { await fetch() }, which can be refactored using the await Promise.all() API.