tarogarden: cache block header verifier results during batch confirmation

[jharveyb]

Related to #314.

Generating proofs for a large batch is liable to time out due to delay from fetching blocks via RPC in the BatchStateConfirmed state.

Specifically, we create a GenHeaderVerifier that will be called at least twice, during proof generation and import. In this part of the state machine, we are repeatedly fetching the same block, which we already fetched and stored before generating these proofs.

We could replace the 'real' headerVerifier with a mock verifier that just checks for block header equality. If we wanted to use header verification for some purpose like reorg detection, it likely shouldn't be done for each proof.

[jharveyb]

This is more tractable now that we have re-org handling. P sure what we want here is to use the caching verifier in BatchStateBroadcast, but NOT use it in planter.updateMintingProofs(), which is what actually handles re-orgs.

We also already have a template for caching verifier callbacks than use an LRU cache. To properly test this we should update the mint batch stress test to generate large blocks.

[jharveyb]

Related, we can now use https://lightning.engineering/api-docs/api/lnd/neutrino-kit/get-block-header in the non-caching header verifier so speed that up as well.

[guggero]

That API is only available to Neutrino backends. We should add a generic one to the chain kit RPC service.

[jharveyb]

Can implement this once lnd 0.17.1 is taped out. We'll need a version check somewhere to create the correct header verifier to match the lnd version.

[jharveyb]

Specifically, we replace this GetBlock call IIUC?

taproot-assets/chain_bridge.go

Line 125 in 3e6579c

_, err = l.GetBlock(ctx, header.BlockHash())

[dstadulis]

@jharveyb has a draft branch of this which works.

Will post it after lightninglabs/lndclient#161 is merged

[dstadulis]

will need to Tag release for lnd-client after lnd release arrives