Benchmark acquirespecificip to nail down performance problems

[majst01]

#146 shows that ip allocation in prefixes with a lot of already allocated ips is slow.

This PR implements a Benchmark which shows this clearly:

 go test -benchmem -run=^$ -tags integration,client -memprofile memprofile.out -cpuprofile profile.out -bench ^BenchmarkAcquireSpecificIPInternal$ github.com/metal-stack/go-ipam
Using postgres:16-alpine cockroach:latest-v23.1 redis:7.2-alpine keydb:latest etcd:v3.5.10 mongodb:7
goos: linux
goarch: amd64
pkg: github.com/metal-stack/go-ipam
cpu: 12th Gen Intel(R) Core(TM) i7-1260P
BenchmarkAcquireSpecificIPInternal/empty_prefix-16                 10000            746019 ns/op          461410 B/op       5024 allocs/op
BenchmarkAcquireSpecificIPInternal/hundert_ips_allocated-16                10000            766130 ns/op          469745 B/op       5125 allocs/op
BenchmarkAcquireSpecificIPInternal/thousand_ips_allocated-16                3232            404067 ns/op          266595 B/op       2790 allocs/op
BenchmarkAcquireSpecificIPInternal/two_thousand_ips_allocated-16            1892            616107 ns/op          381988 B/op       4035 allocs/op
BenchmarkAcquireSpecificIPInternal/five_thousand_ips_allocated-16              1        1819201577 ns/op        1182815640 B/op 12581364 allocs/op
PASS

looking at the cpu profile, we can see that most of the time is spent in the deepcopy function of a prefix.

This is the cpu profile running this benchmark with an empty prefix:

And this shows the cpu profile with 5000 already allocated ips:

Graphs are generated with:

go tool pprof profile.out
File: go-ipam.test
Type: cpu
Time: May 11, 2024 at 9:41am (CEST)
Duration: 23.68s, Total samples = 27.24s (115.04%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) web

[majst01]

This will not be merged because the Issue reported was because the benchmark is doing two loops inside each other which is responsible for a exponential increase in ip allocation time measured.