Cap error heap usage

[Jake-Shadle]

This is a rework of #986

This resolves an unbounded memory growth issue that can occur in a particularly hostile context, ie, every packet is invalid in some way, generating an error, and CPU usage is high enough that tasks, notably

quilkin/src/components/proxy/packet_router.rs

Lines 272 to 295 in 50d91e4

	tokio::spawn(async move {
	let mut log_task = tokio::time::interval(std::time::Duration::from_secs(5));
	let mut pipeline_errors = std::collections::HashMap::<String, u64>::new();
	loop {
	tokio::select! {
	_ = log_task.tick() => {
	for (error, instances) in &pipeline_errors {
	tracing::warn!(%error, %instances, "pipeline report");
	}
	pipeline_errors.clear();
	}
	received = error_receiver.recv() => {
	let Some(error) = received else {
	tracing::info!("pipeline reporting task closed");
	return;
	};
	let entry = pipeline_errors.entry(error.to_string()).or_default();
	*entry += 1;
	}
	}
	}
	});

do not consistently receive CPU time. In this context, where every received packet generates an error, which is then sent to an unbounded channel before being dequeued, the dequeue task might not run quickly enough to dequeue each error, causing both the memory allocated by the error, as well as by the queue, grow quickly enough that the process can be OOM killed.

This PR changes it so that instead of each error being sent to an unbounded channel, the errors are instead accumulated by the receive tasks themselves, and those accumulations being sent to the print task once they reach a cap, or a certain amount of time since the first error was pushed has elapsed to a bounded channel. If the bounded channel is full and too many errors are accumulated on a particular receive task, we drop the errors and note that it happened, rather than risk consuming too much heap memory.

Previously:

This PR:

While investigating I ran into a bug with xDS filterchain where the server will send empty delta updates, so now the server doesn't send updates if the resource(s) haven't changed.

Also added 2 ways to generate unique tokens, one where n tokens of length l are generated and written to ./quilkin-test-config.yaml that can be used with -c, and the other is with a new --to-tokens arg on proxy that can do the same, assigning unique tokens of a specific length to each address in --to.

Resolves: #983

[quilkin-bot]

Build Succeeded 🥳

Build Id: d2794817-c17c-442a-ab47-3ba5ba9930af

The following development images have been built, and will exist for the next 30 days:

• us-docker.pkg.dev/quilkin/ci/quilkin:0.9.0-dev-ed05d32

To build this version:

git fetch git@github.com:googleforgames/quilkin.git pull/987/head:pr_987 && git checkout pr_987
cargo build