ethclient: fix flaky pending tx test

[kashitaka]

Fixes: #32252

This PR fixes an issue where testAtFunctions fails because of timeout.

Cause

The issue caused by infinite loop in the test here:

go-ethereum/ethclient/ethclient_test.go

Lines 513 to 523 in c3ef6c7

	for {
	// Check pending transaction count
	pending, err := ec.PendingTransactionCount(context.Background())
	if err != nil {
	t.Fatalf("unexpected error: %v", err)
	}
	if pending == 1 {
	break
	}
	time.Sleep(100 * time.Millisecond)
	}

Although the transaction is sent to the backend, it sometimes keeps returning a pending transaction count of 0, never reaching the break condition. I was able to reproduce this failure locally, albeit rarely—about 1 in every 1000 test runs.

In the successful cases, pendingNonceAt returns 2, which is consistent with inserting a block containing two transactions via InsertChain when initializing the test backend. However, in the failing cases, pendingNonceAt returns 0.

Root Cause

The issue is caused by a race condition between invoking InsertChain and the startup of the txpool's background process that updates subpool's pendingNonces when initializing test backend.

The failure occurs because the pendingNonces inside the txPool's subpools does not have the correct nonce information. This is due to the fact that when the blocks are inserted via InsertChain, the txpool.loop() has not yet started running, so the background processing that updates the state does not occur.

In the regular cases, txpool.loop receives the updated head when the blocks are inserted, triggering subpool.Reset(oldHead, newHead). Then, inside LegacyPool.runReorg, pendingNonces is properly updated.
In the failure pattern, however, blocks are ALWAYS inserted before txpool.loop() has started, so pendingNonces is never updated.

Reproduction

The issue can be reliably reproduced by adding time.Sleep(1 * time.Second) at the beginning of txpool.loop. This delay causes the test to consistently fail, confirming the presence of a race condition.

Solution

I found that we already have a handy function txpool.Sync() to wait for txpool starting its background loop. We can use it and fix the flakyness.

[kashitaka]

@rjl493456442 I identified the cause of the issue, so I close #32329 and submit this PR. Please take a look when you have time.

[kashitaka]

The error was unhandled, so I added error handling to make debugging easier.