loader: fix issue where errors cancelled compile cause error logs.

[tommyp1ckles]

On Linux/Unix based implementations, exec/cmd.Run will return either context.ContextCancelled or the error "signal: killed" depending on whether the cancellation occured while the process was running.

There's several places we check on is.Errors(err, context.Cancelled) on whether to emit high level logs about failed program compilations. Because already running cmd.Run() doesn't return an error that satisfies this, this will result in spurious error logs about failed compilation (i.e. "signal: killed")

This meant that in cases where a compilation is legitimately cancelled, we would still log an error such as

msg="BPF template object creation failed" ... error="...: compile bpf_lxc.o: signal: killed"

This can occur occasionally in CI, which enforces no error to pass, causing failures.

example:

	ctx, c := context.WithTimeout(context.Background(), time.Second)
	go func() {
		time.Sleep(time.Second)
		c()
	}()
	cmd := exec.CommandContext(ctx, "sleep", "2")
	fmt.Println(cmd.Run())

	ctx, c = context.WithTimeout(context.Background(), time.Second)
	c()
	cmd = exec.CommandContext(ctx, "sleep", "2")
	fmt.Println(cmd.Run())

To fix this, this will join in the ctx.Err() if it is:

• context.Cancelled
• The process has not exited itself.
• The process appeared to be SIGKILL'ed.

Addresses: #30991

[tommyp1ckles]

/test

[tommyp1ckles]

/test

[tommyp1ckles]

/test

[tommyp1ckles]

/test

[julianwiedmann]

👋 if this occurs in CI, should we also backport to older releases for reducing flakes?

[tommyp1ckles]

@julianwiedmann I didn't notice it happening in other branches, I think the uptick in these failing CI was also related to other changes in 0.16.0. However, this does seem like a minor bug either way so I think we can justify backporting this.