Batch events

[pleshakov]

Proposed changes

Previously, the Gateway would handle one event (upserting or deleting a
Kubernetes resource) at a time.

This PR introduces event batching: multiple events (a batch) are
handled at once.

Batching is needed because, because typically handling an event (or
multiple events at once) will result into reloading NGINX, which is
the operation we want to minimize, for the following reasons:
(1) A reload takes time - at least 200ms. The time depends on the size
of the configuration including the number of TLS certs, available CPU
cycles.
(2) A reload can have side-effects for the data plane traffic.

Now, when a new event comes, there are two cases:

• If there is no event(s) currently being handled, the new event is
  handled immediately.
• Otherwise, the new event will be saved for later handling. All saved
  events will be handled after the handling of the current event(s)
  finishes. Multiple saved events will be handled at once in one batch.

Additional implementation notes:

(a) The EventLoop was split into two parts:
(1) The EventHandler, which is only responsible for handling a batch of
events, without dealing with concurrency.
(2) The stripped-down EventLoop, which is responsible for batching events
and propagating batches to the EventHandler in a dedicated goroutine.

(b) The ChangeProcessor was fixed, so that when multiple changes are
captured (coming from a single batch) -- first, changes that cause
data plane reconfiguration, followed by changes that do not cause
reconfiguration -- in that case, the data plane will be reconfigured.
Without the fix, the latter changes would prevent data plane from
reconfiguring. Note that the bug only appeared when batching was added.

[kate-osborn]

🚀