Remove the approximate finalization for non-finalization chains

[ianhe8x]

Description

We currently use --block-confirmation to approximate block finalization. This may cause data inconsistency when dealing with non-finalization chains like polygon since we don't know how many blocks is enough and hard to get a balance between safety and experience.
And it is confusing that what --unfinalized-blocks means to such chain, shouldn't it always be treated --unfinalized-blocks?

We should recommend --unfinalized-blocks for these chains, unless the target database doesn't support this feature(cockroachdb). Change the way we find forks for such chain.

Details

1. when a chain is a non-finalization chain, print warning if --unfinalized-blocks is not used
2. when --unfinalized-blocks enabled, --poi also need to be enforced, because new fork locating logic rely on poi table.
3. when a chain is a non-finalization chain and --unfinalized-blocks enabled
4. ignore --block-confirmation, print warning if it is passed.
5. change the fork block finding logic, since we can not rely on finalized height to quickly locate fork.

Fork Finding Logic

1. Make sure recent blocks are continuous and cached
2. Any new block arrives, use parentHash to detect if fork happened.
3. Search backwards for blocks there is db operation one by one (cache in memory), compare blockhash with the block retrieved from chain rpc and locate fork.
4. Rollback after found the fork and reset block cache when

Any other information

Is there any other information you would like to add?

[ianhe8x]

Made some changes to the original ideas. Since now I tend to think index on wrong fork is inevitable (in extreme scenario) without compromising the performance.

1. The first compromise is to accept --block-confirmation, and
   a) fork detection can not rely on the psuedo finalized height marked by --block-confirmation, we need to use parentBlockHash chains
   b) --block-confirmation need to be align with the cached headers in metadata (or memory)
2. stop and resume is a high risky scenario we need to address

TBD

[stwiname]

Fixed in subquery#217