feat: log poller for vrf v2/v2+

[makramkd]

Switch over the VRF V2 listener to use the log poller instead of the log broadcaster.

Summary of Changes

1. Transform the log processing loop of the VRF listener to the following (pseudocode, see runLogListener in listener_v2_log_listener.go for the gory details):

ticker := time.NewTicker(pollPeriod)
var (
	lastProcessedBlock int64
	startingUp         = true
)
for {
	case <-stop:
		return
	case <-ticker.C:
		err := registerLogPollerFilter()
		if startingUp {
			lastProcessedBlock = initLastProcessedBlock()
			startingUp = false
		}
		pending := pollLogs(lastProcessedBlock)
		// adds sent fulfillments to inflight cache
		processPendingRequests(pending)
		lastProcessedBlock = updateLastProcessedBlock(lastProcessedBlock)
}

The effect of this is that the processing loop of the VRF listener is much simpler, concurrent access to lsn.reqs is no longer needed, and in fact the reqs in-memory queue can be completely removed, as well as any associated data structures to protect it from data races. The function runRequestHandler has also been removed, since pending request processing is in the same loop as the log polling.

2. Separate the VRF listener code into four files to make grokking things easier:
   a. listener_v2_log_listener.go: this file contains all log polling and listening logic, as well as the main loop runLogListener. This is the entrypoint into the functionality of the VRF listener. This file contains the lion's share of new code in this PR, mainly the revamped runLogListener, and the new initializeLastProcessedBlock, updateLastProcessedBlock, and pollLogs methods.
   b. listener_v2_log_processor.go: this file contains all log processing logic, the entrypoint of which is processPendingVRFRequests. Notably, processPendingVRFRequests marks all in-flight fulfillments in the inflightCache cache, so that these requests don't get reprocessed. Most of the code in this file is unchanged and was simply copied over from listener_v2.go.
   c. listener_v2_helpers.go: contains helper functions and types, extracted from listener_v2.go.

[github-actions]

I see that you haven't updated any README files. Would it make sense to do so?

[makramkd]

After running a short load test it seems that this approach of having everything in a single loop has actually caused a regression in performance on the simulated networks we use for load tests.

I'm not sure of what is causing it, perhaps the log poller interval is too high, and perhaps the VRF job interval is also too high. If so I'll set them appropriately and run the test again.

[makramkd]

Update: after bumping log poll interval down to 1s the load tests are looking on-par with the log-broadcaster-based VRF listener in the simulated environment.

[jinhoonbang]

Still reviewing! Mostly looked at the new main LP logic

[cl-sonarqube-production]

SonarQube Quality Gate

12.32% Duplicated Lines (%) on New Code (is greater than 3%)

See analysis details on SonarQube