pkg/bpf: fix bug where bpf map entries may not be reliably dumped.

DumpReliablyWithCallback will skip a value callback in some situations.
This may result in incorrect cilium map dumps or garbage collection.

In situations where the initial key is deleted just after being retrieved, there is no previous key to fallback on.
The reliable dump will attempt to use the current nextKey (that was based on the deleted current
key).

The local currentKey and nextKey Key types are being passed to NextKey
which eventually writes the nextKey output to the nextKeys pointer
location (via the bpf syscall).

The currentValue was simply being assinged by the equals operator, which
was copying the underlying interface pointer.

Thus in this situation, the next iteration attempt was passing the same
pointer twice to NextKey causing the currentKey to be set to the next
key a second time - skipping a map element.

Fixes #26491

Signed-off-by: Tom Hadlaw <tom.hadlaw@isovalent.com>

pkg/bpf/map_linux.go

@@ -672,6 +672,11 @@ func (m *Map) DumpReliablyWithCallback(cb DumpCallback, stats *DumpStats) error
 				// map, nextKey may be the actual key element after the deleted
 				// one, or the first element in the map.
 				currentKey = nextKey
+				// To avoid having nextKey and currentKey pointing at the same memory
+				// we allocate a new key for nextKey. Without this currentKey and nextKey
+				// would be the same pointer value and would get double iterated on the next
+				// iterations m.NextKey(...) call.
+				nextKey = m.key.New()
 				stats.Interrupted++
 			}
 			continue