Refactor Load() and fixup BPF lifecycle

[SirNexus]

There are a few issues with our current implementation that makes working with eBPF programs a bit less straightforward.

1. In our loader code (example), we defer <link>.Close. This means that as soon as the function exits, we close the loaded BPF program. This makes sense, as, per the function documentation, “A link may continue past the lifetime of the process if Close is not called.” The problem though with this is that there are instances where we want to lifetime of the program to live past this function. Cases such as:

• A user pins the program or maps to the filesystem, in which case it doesn’t make sense to close this loaded function
• A user runs the bee loader on a BPF program that doesn’t contain any maps

2. Pertaining to the second bullet point above, bee does not operate correctly when a user loads a BPF program that doesn’t contains maps to watch. In this case, when running either by default or in --no-tty mode, the program gets unloaded immediately (as the WatchMaps() function will exit immediately and therefore the defer call will be executed promptly)

• This problem leads to a greater overarching architectural inefficiency in that the WatchMaps() function lives within the lifecycle of the Load function call. These bits of functionality should be disparate, and be called separately – therefore allowing the lifecycle to be managed explicitly by the caller. This is the onus behind the greater mapwatcher folder refactor. This package is still tied to the loader, but instead lives in a subdirectory – allowing it to be called separately based on the needs of the caller. You’ll find that this is beneficial when running in --no-tty mode, in which case we no longer have to create a dummy NoopWatcher just to call the Load() function. Instead we can call load and then just wait for the context of the program to be canceled.