guess: tie the state machine to a single thread

[alban]

By default, Golang does not guarantee that a go routine will always be executed on the same system thread (tid). During the guessing work, the tcp connections could be generated from various threads. The ebpf program was accepting any connections as long as it come from the correct process, regardless of threads.

This patch changes this to have stricter rules:

• the ebpf program only accept guessing connections that comes from the expected pid & tid.
• the userland guessing work takes care of using the thread specified in the status map. In Golang, this is done with runtime.{Lock,Unlock}OSThread.

---

TODO:

• [x] check for possible regressions in Scope
• [ ] I am expecting this to fix the flaky test "311_container_to_container_edge_with_ebpf_test" in Scope (see https://github.com/weaveworks/scope/pull/2346). I should test if it is really the case.

/cc @iaguis @schu

[alban]

Unfortunately, @schu managed to reproduce the issue even with this PR.

But I think this PR is an improvement, even if it does not fix the issue.

[schu]

We continue testing 311_container_to_container_edge_with_ebpf_test. What we know:

• Offset guessing doesn't always fail at the same step (so far we saw failures during source address and source port offset guessing)
• The failure happens only sporadic (sometimes after ~10 test runs, sometimes not in 50 runs)
• I haven't managed to reproduce it on my local machine (only on GCE)
• dmesg doesn't show anything suspicious