Compatibility with new NetBox versions

[bruelea]

Changes

• This MR introduces a change to set the 'mark-populated' flag to true for all ip-ranges that are managed with the operator.
• Depending on the NetBox version used for prefix create and update requests the site is added to the site or the scope field of a prefix

Reason

In NetBox 4.2 the behavior of the api/ipam/prefixes/{id}/available-ips/ changed. In older versions ip adresses in an ip-range were considered "used". In a version between v4.1.10 and v4.3.0 this behavoir changed, so that ip addresses in an ip-range are considered as free by default.

In v4.3.0 the flag 'mark-populated' was introduced. If it is set to true the ip adresses in the ip range will be considered as used. https://netboxlabs.com/docs/netbox/release-notes/version-4.3#v430-2025-05-01

In v4.20 the site field was removed form the prefix object and replaced with a scope field.

NetBox Upgrade

When upgrading NetBox to a version newer than v4.3.0 it's recommended to pause NetBox operator during the upgrade and add the 'mark-populated' flag to the ip-ranges managed by NetBox Operator as part of the upgrade. Otherwise, if new ip or ip-ranges are claimed, NetBox Operator will try to claim overlapping ip addresses until all managed ip-ranges have the 'mark-populated' flag set to true.

The script 'scripts/mark-ip-ranges-populated.py' can be used to patch the 'mark-populated' field to true.

Limitations

The NetBox versions between the version where the change happened an v4.3 are not compatible with NetBox operator.

[faebr]

I think its not so good practice that one client is passed as a parameter to the other client. But since the legacy client is only temporarily I think this is acceptable if the changes required to prevent this are big.
I locally deployed all 4 netbox versions from the makefile one after the other. I was only able to leave the same kind cluster and netbox-operator running for the first 3. The last upgrade step forced me to reset my cluster I believe due to redis -> valkey change. So could not locally test this upgrade, but from clean deployment worked great. Nice job!

[bruelea]

Thanks for the suggestions and the thorough testing! I still refactored the api package to make it easy to replace more v3 requests with v4 request in the future. And to have cleaner code even if the v3 client won't completely be phased out.

I haven't changed the type of the id's yet but can align them to int64 if we want to keep it the same for all the resources.