Use ticker instead of time.After in select loop (#2621)

Repeatedly using time.After in a select loop leaks resources as
resources are allocated for each timer, but not released until the
timer fires. The timer may not fire due to other return paths. By
using tickers, this resource leak is no longer able to happen.

I verified that this problem no longer exists with the following
semgrep command.
semgrep --config="r/dgryski.semgrep-go.timeafter.leaky-time-after"
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

op-e2e/geth.go

@@ -29,6 +29,8 @@ import (
 
 func waitForTransaction(hash common.Hash, client *ethclient.Client, timeout time.Duration) (*types.Receipt, error) {
 	timeoutCh := time.After(timeout)
+	ticker := time.NewTicker(100 * time.Millisecond)
+	defer ticker.Stop()
 	ctx, cancel := context.WithTimeout(context.Background(), timeout)
 	defer cancel()
 	for {
@@ -42,7 +44,7 @@ func waitForTransaction(hash common.Hash, client *ethclient.Client, timeout time
 		select {
 		case <-timeoutCh:
 			return nil, errors.New("timeout")
-		case <-time.After(100 * time.Millisecond):
+		case <-ticker.C:
 		}
 	}
 }

op-proposer/service.go

@@ -101,10 +101,12 @@ func (s *Service) eventLoop() {
 	defer s.wg.Done()
 
 	name := s.cfg.Driver.Name()
+	ticker := time.NewTicker(s.cfg.PollInterval)
+	defer ticker.Stop()
 
 	for {
 		select {
-		case <-time.After(s.cfg.PollInterval):
+		case <-ticker.C:
 			// Determine the range of L2 blocks that the submitter has not
 			// processed, and needs to take action on.
 			s.l.Info(name + " fetching current block range")

op-proposer/txmgr/txmgr.go

@@ -205,12 +205,15 @@ func (m *SimpleTxManager) Send(
 	wg.Add(1)
 	go sendTxAsync()
 
+	ticker := time.NewTicker(m.cfg.ResubmissionTimeout)
+	defer ticker.Stop()
+
 	for {
 		select {
 
 		// Whenever a resubmission timeout has elapsed, bump the gas
 		// price and publish a new transaction.
-		case <-time.After(m.cfg.ResubmissionTimeout):
+		case <-ticker.C:
 			// Avoid republishing if we are waiting for confirmation on an
 			// existing tx. This is primarily an optimization to reduce the
 			// number of API calls we make, but also reduces the chances of