fix(probe/ebpf): feed initial connections synchronously on restart

[bboreham]

Fixes #3711

If we run getInitialState() async there is some chance we will see another ebpf failure and call useProcfs() before getInitialState() gets to the last line, whereupon it will crash on nil pointer.

Also it seems pointless to call performEbpfTrack() without waiting for something to feed in, so I suspect this is what the original author had in mind.

It will slow down this one Report() on machines with a lot of processes or connections, but EbpfTracker restart is supposed to be a rare event.

[fbarl]

Don't know how to test this properly but the arguments make sense :)

There is one more instance where getInitialState() is called async on initial creation, shall we consider making it sync there as well, or do the same arguments not apply in that case?

[bboreham]

It makes sense to feed async on startup, because Report() won't get called until about 1 second later.
And it's not possible for useProcfs() to get called after that until we've gone through the synchronous path. This isn't complete protection against the crash, since it's possible the first invocation takes a really long time and the second one is quick.

I could change it to pass t.ebpfTracker into getInitialState(), then it wouldn't crash.

[fbarl]

I could change it to pass t.ebpfTracker into getInitialState(), then it wouldn't crash.

Yeah, if it's not a big change, I think I'd be nice to remove the risk in this PR :)

[bboreham]

@fbarl are you ok with the refactoring to remove that risk?

[fbarl]

@fbarl are you ok with the refactoring to remove that risk?

Yes, still LGTM, feel free to merge!