Fixes #11934 - Clear previous primary ip assignment on edit

[kkthxbye-code]

Fixes: #11934

Kinda icky fix, but we are reassigning the assigned object in the clean method, so didn't see any other way that wouldn't add more queries.

[kkthxbye-code]

This fix is actually not enough. Editing the primary IP for device1, removing the primary ip checkbox and assigning the ip to device2 will not clear the primary IP of device1 leaving it referencing an IP not assigned to any of its interfaces.

The code is already messy imo, so not sure what the right approach is here. @jeremystretch suggested in the issue to throw validation errors instead, although I think the usability suffers a little it might be the right way to go.

[jeremystretch]

It seems like we need to devise a mechanism to check for existing primary IP assignments (from all possible objects) when validating the updated IP address. I'm sure we could hack something together, but this might be an opportunity to re-think the underlying data model.

Currently, we have primary_ip4 and primary_ip6 ForeignKeys defined on the Device and VirtualMachine models. (In its current form, #8137 would also add an oob_ip ForeignKey for Device.) We could instead model this relationship via an intermediary table, mapping objects to individual IP addresses. This would allow for more robust management of primary IP assignments, however further consideration is needed.

[ITJamie]

an intermediary relationships table could be very useful... it could allow for the possibility of other "service" ip's (probably not the best term) to be assigned.

for example some san's have multiple different ip's for difference types of management, firmware level (drac/oob),
a hypervisor/ha manager level, then the actual "os" being having the primary_ip.

[DanSheps]

We could instead model this relationship via an intermediary table, mapping objects to individual IP addresses. This would allow for more robust management of primary IP assignments, however further consideration is needed.

I like this approach. It would allow us to extend things such as oob_ip, primary_ip, etc. The only sticking point is it is going to need to be a GFK (or two fields) to the device/vm which makes the form slightly complicated.

With an intermediary table you can also allow user defined "roles" with a Choice field (For the intermediary table you have your uniqueness validate on ip, ip family, v4 vs v6 as well as device, role and family) that is extensible such that you can have an oob ip, a primary ip and perhaps users could add things like ipmi, console, whatever.

[ITJamie]

combined with custom validators that would that would be very powerful for business logic

[jeremystretch]

As a more thorough solution to the root issue here is expected to involve an almost certainly breaking change to the data model, I've opted for now to simply disable the reassignment of an IP address that has been designated as primary for its parent object in b64b19a. (This is not currently possible anyway as it triggers the exception documented above.)