daemon, lbmap: Avoid premature initialization of BPF maps

[christarazi]

There is a flag called --bpf-lb-map-max that controls the maximum
number of entries in BPF LB maps. When this is set, it updates
lbmap.MaxEntries which is a package-level variable. All LB maps use
this variable to configure their maximum size.

However, due to bpf.NewMap() being called at the package-level (to
initialize "cilium_lb4_services_v2", "cilium_lb4_backends", etc.)
because it's in a var() block, lbmap.MaxEntries has not been updated
yet with the value passed from the aforementioned flag.

Ultimately, this means that the flag was never respected, meaning the
user was never able to change the maximum size of their BPF LB maps.

The reason lbmap.MaxEntries wasn't updated is because Golang will
initialize variables defined in the var() block as soon as the package
is imported, aka before main() [1]. In this case, whenever the lbmap
package was first imported, then the call to bpf.NewMap() was made
with the yet-to-be updated lbmap.MaxEntries. Only after this has
happened (main() begins execution), then Cilium will eventually get to
reading the flag value and updating lbmap.MaxEntries.

This commit avoids the initialization at the var() block and instead
defines explicit initialization functions to be called when appropriate,
in this case, after reading the flag and updating lbmap.MaxEntries,
inside lbmap.Init().

This was found by running scale tests against the service code, e.g.
creating 1000+ backends per service. The following error was observed
and has been fixed with this commit:

[PUT /service/{id}][500] putServiceIdFailure  Unable to update service entry 1.1.0.131:36895 => 2871 (37415) [FLAGS: 0x0]: Unable to update element for map with file descriptor 14: argument list too long

[1]: See below for excerpt. Source:
https://golang.org/ref/spec#Program_initialization_and_execution

Within a package, package-level variable initialization proceeds
stepwise, with each step selecting the variable earliest in
declaration order which has no dependencies on uninitialized
variables.

[...]

A package with no imports is initialized by assigning initial values
to all its package-level variables followed by calling all init
functions in the order they appear in the source, possibly in
multiple files, as presented to the compiler. If a package has
imports, the imported packages are initialized before initializing
the package itself. If multiple packages import a package, the
imported package will be initialized only once. The importing of
packages, by construction, guarantees that there can be no cyclic
initialization dependencies.

Package initialization—variable initialization and the invocation of
init functions—happens in a single goroutine, sequentially, one
package at a time. An init function may launch other goroutines,
which can run concurrently with the initialization code. However,
initialization always sequences the init functions: it will not
invoke the next one until the previous one has returned.

Fix bug where Cilium did not respect `--bpf-lb-map-max` and wouldn't update the maximum size of BPF LB maps

[christarazi]

test-me-please

[christarazi]

CI has passed. Taking this opportunity to fix typos in commit msg and because the GH Actions never got triggered, to push again.

[brb]

test-4.19

[christarazi]

test-me-please

[brb]

test-gke

[brb]

Thanks! As a follow-up we can get rid of more globals (e.g. s/MaxEntries/params.MaxEntries/).