Relax prefix type consistency checks #530
Description
Our current model enforces that the user specifies how a prefix is "used" in the network by specifying the type, which is one of 'host', 'assignment' or 'reservation'. Type host represent a single address in a network. Assignments means "network containing hosts", while 'reservation' are networks without hosts which you often don't find configured anywhere in your network, rather they only exist in NIPAP to show structure and serve as reservation of a network to be further divided.
Anyway, it's rather annoying that users have to understand this. Trying to register hosts in a 'reservation' prefix won't work and the 'assignment' and 'reservation' keywords are often confused with RIPE nomenclature.
Further, since our API doesn't support batching and the way the triggers are implemented, it is essentially impossible to move an assignment. For example, if we have the network 1.3.3.0/24 (assignment) with a number of hosts (1.3.3.1/32..1.3.3.7/32), we could not simply move that to 2.3.3.0/24 with all the hosts in the same relative position. Nor is it possible to move between VRFs. Even with a "recursive move" function in the API, I think it would be implement in the database given the current triggers.
I suggest that we relax our prefix type consistency checks and remove the visibility of the prefix type as it is today. Instead we have two "types"; 'network' and 'host' - which are very familiar concepts to anyone who has worked with networks. The kind of consistency model that we have today would remain but instead of blocking operations we would instead mark hosts as 'orphans' if there isn't a suitable network to cover it. phpipam has the concept of orphans...
We could do this internally simple by registering new networks as 'reservation' (1.3.3.0/24). If someone adds a host in the network (1.3.3.7/32), the type (of 1.3.3.0/24) is changed to 'assignment' - essentially to mean 'this network has hosts in it'. Now if someone adds a subnet like 1.3.3.128/25 in 1.3.3.0/24 it means 1.3.3.0/24 would have both a host and a network as children, which isn't allowed. 1.3.3.0/24 would then change type back to reservation and 1.3.3.7/32 would be marked as orphan (new column in database).