hubble/recorder: Extend the API to allow stopping a recording automatically

[gandro]

This implements a feature to stop a recording as soon as one of
three optional stop conditions are hit. If a stop condition is hit, the
RecordingStoppedResponse is sent to the client the same way
it would if the client requested an explicit stop request.

The StartRecording API message is extended with a new (optional) StopCondition field:

// StopCondition defines one or more conditions which cause the recording to
// stop after they have been hit. Stop conditions are ignored if they are
// absent or zero-valued. If multiple conditions are defined, the recording
// stops after the first one is hit.
message StopCondition {
    // bytes_captured stops the recording after at least this many bytes have
    // been captured. Note: The resulting file might be slightly larger due
    // to added pcap headers.
    uint64 bytes_captured = 1;
    // bytes_captured stops the recording after at least this many packets have
    // been captured.
    uint64 packets_captured = 2;
    // nanoseconds_elapsed stops the recording after this duration has elapsed.
    uint64 nanoseconds_elapsed = 3;
}

We ensure that the stop conditions are hit as early as possible,
to avoid writing more bytes or packets than necessary.
While this can also be implemented client-side by observing the
statistics of the running recording and issuing an explicit stop
request, it can be useful to implement some basic stop conditions
server-side as a fail-safe in case the client becomes unresponsive but
is still connected.

[gandro]

test-me-please

[rolinh]

nit: I think that bytes_captured_count and packets_captured_count would be better names because the current ones sound a bit like they'd be boolean values.

[glibsm]

also num_bytes and num_captured could work or even bytes/packets one word

[gandro]

Sure, will change!

[gandro]

Going with packets/bytes_captured_count. The reason I prefer to actually include captured is to make clear that it refers to these values here:

cilium/api/v1/recorder/recorder.proto

Lines 110 to 121 in 6f9b875

	message RecordingStatistics {
	// bytes_captured is the total amount of bytes captured in the recording
	uint64 bytes_captured = 1;
	// packets_captured is the total amount of packets captured the recording
	uint64 packets_captured = 2;
	// packets_lost is the total amount of packets matching the filter during
	// the recording, but never written to the sink because it was overloaded.
	uint64 packets_lost = 3;
	// bytes_lost is the total amount of bytes matching the filter during
	// the recording, but never written to the sink because it was overloaded.
	uint64 bytes_lost = 4;
	}

We might want to add other filters in the futures, e.g. bytes_lost_count or maybe even bytes_written_count (for the actual bytes written to disk, which includes things like pcap headers)

[glibsm]

also num_bytes and num_captured could work or even bytes/packets one word

[gandro]

test-1.19-5.4 hit #16479 - which is about to be fixed, so I will restart the tests after I addressed the above feedback.

https://jenkins.cilium.io/job/Cilium-PR-K8s-1.19-kernel-5.4/736/testReport/junit/Suite-k8s-1/19/K8sDatapathConfig_Transparent_encryption_DirectRouting_Check_connectivity_with_transparent_encryption_and_direct_routing/

[aanm]

/mlh new-flake Cilium-PR-K8s-1.19-kernel-5.4

👍 created #17010

[gandro]

test-me-please