Sync logic change proposal

Current sync logic of explorer is very inefficient for importing various informations via different web3 calls.

So I would like to propose and adopt a new db import logic for explorer.

Current method:

1. Checks latest block number

2. Sync starts from latest block number to genesis block in "descending" order.

3. Fetch new blocks while on initial sync

4. Account list & BlockStats should be run on different process

New method:

1. Checks if the node is on sync

2. Checks latest block number on node

3. Sync starts from genesis block to latest "detected" block number in "ascending" order.

4. Fetch account list and blockstats in parallel with block & tx collection. ( Use listAccounts method and rescan option if it is a first sync or db document not exists on db )

5. If the initial sync is finished then fetch new blocks and transactions via web3.eth.subscribe method.

6. eth.subscribe will report multiple blocks in a single call if the reorg happens, then update the document and move reorged blocks in different collection.

cc @hackmod @realcodywburns

Start by tracing the explorer's current sync logic and its web3 calls, including the node-sync and latest-block checks, listAccounts, and eth.subscribe. Compare the existing flow with the proposed ascending initial import, parallel account and blockstats work, subscription-based updates, and reorg handling; done means those behaviors are specified and implemented consistently.