Batch map lookups may fail with ENOSPC

[nARN]

items_lookup_batch and items_lookup_and_delete_batch may fail with ENOSPC, when the map is close to its max_entries.

Batch lookups are inherently non-atomic, as the map may change between reads, making it possible to go over max_entries, as long as BPF programs keep updating the map as it is read.

Limiting count appears to be insufficient, as internally iteration is over buckets and if the requested count is smaller than the size of the bucket ENOSPC is returned. This happens when _items_lookup_and_optionally_delete_batch has accumulated items close to max_entries and has only few elements worth of allocated space left, which turns out to be less than the size of the next bucket in the iteration.

Perhaps, ENOSPC can be simply swallowed, although in hypothetical severe cases that would mean last buckets may be repeatedly left behind.

A more mathematically correct way would be to always allocate more and continue fetching elements until the map has been traversed in full. Theoretical maximum number of elements would be max_entries * n_buckets, but that is almost impossible in practice, so not a big concern, perhaps.