Allow room names to be changed in SeedDB

[lunkwill42]

Is your feature request related to a problem? Please describe.

Several users have found at some point that they wish to rename their NAV rooms (i.e. the physical room is the same, just its identifier or number has changed). This is not currently possible in SeedDB, most likely because the room name is also its unique ID and database primary key.

Describe the solution you'd like

SeedDB should allow changing the room id of a room as long as the new name is still unique.

Describe alternatives you've considered

An alternative, but potentially much larger operation would be the feature suggested by #1377.

Additional context

UiT comments that the biggest pain point here is that SeedDB disallows changing room names. It forces the users to move all devices to a new room. However, there is nothing in the underlying DB that prevents renaming of a primary key.

Originally posted by @lunkwill42 in #1377

The room.roomid field is a string primary key. There isn't anything inherently preventing us from changing a primary key value in the database, but it can get somewhat tricky depending on how many records reference the key. These are the hard foreign keys in the current schema:

TABLE "cabling" CONSTRAINT "cabling_roomid_fkey" FOREIGN KEY (roomid) REFERENCES room(roomid) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "image" CONSTRAINT "image_roomid_fkey" FOREIGN KEY (roomid) REFERENCES room(roomid)
TABLE "netbox" CONSTRAINT "netbox_roomid_fkey" FOREIGN KEY (roomid) REFERENCES room(roomid) ON UPDATE CASCADE
TABLE "rack" CONSTRAINT "rack_roomid_fkey" FOREIGN KEY (roomid) REFERENCES room(roomid) ON DELETE CASCADE

There are no database constraints preventing us from changing a primary key here, as it would automatically cascade to these tables, which presumably do not contain wildly many referencing rows.

From memory, one tricky point could be maintenance tasks. Maintenance tasks can reference rooms as one of their components, and since this are implemented as generic foreign keys, they will not be enforced by the database, only at the application level. The most portable way of fixing this might be to add a database rule that updates all maintenance component entries that reference a roomid that is being changed.

There may also be references to room IDs in users' alert profiles. These are not foreign key relations at all (the matching values are usually selected from a dropdown, but nothing enforces a database referential integrity here). One can even write profile filters that to substring or partial matches against room ids. I don't see how we could reliably migrate such profiles in the event of a room rename, so our best option here might be to warn the admin that renames a room that they need to ask all their users to inspect their alert profile filters to ensure they still match after a room rename.