Post-Migration Tool: Deduplicate IP Addresses

[bryanculver]

As discussed we brainstormed about a list view of IPAddress objects where host address is found in multiple Namespaces. Clicking through to that address presents a secondary list view of each IPAddress and its Namespace and parent and other important fields.

The UI for merging duplicate IPAddress objects would be something like a bulk edit view, where one can select the objects they wish to merge and the one they wish to merge into as the "primary" record, also selecting which field values to keep or merge into the "primary" record.

Consider a use-case where a user might be tracking link-local IPv4 addresses (e.g. 169.254.0.1/32) across numerous interfaces each with a unique description. Post-v2 upgrade all but one of them will likely end up spread across various "Cleanup Namespaces". The intent of this tool would be to provide a way to merge all of these back into a single record.

The underlying reason for this being that the primary goal for the v2 IPAM data migrations is to not have any data loss. The v1 data model required the creation of duplicate IPAddress objects in several cases, the most common of which would be assigning IPs to Interfaces, which in v1 was inverted where the foreign key was from IPAddress to Interface. In v2 this is inverted where there is a many-to-many from Interface to IPAddress, thereby eliminating the need to maintain duplicate IPAddress objects just so that the same host address can be assigned to multiple Interfaces.

Therefore, the thought is that if this duplication of IPs can be done, it should be done. Nuance and care will have to be considered for what to do about the case where these duplicate IPAddress objects in each Namespace may be assigned to an Interface, and may need to be swapped with a relationship to the "primary" IPAddress record as a part of the deduplication process.

[HanlinMiao]

Closed by #3986