Want transaction/rollback support for installing sets of rules

[FelixMcFelix]

An earlier version of #490 manipulated allow-cidr logic by inserting an inbound and outbound rule in sequence. This introduced an error where failing to add the second rule would leave the first rule in place. The correct behaviour would have been to rollback to the original state and report an error.

For ioctls of similar scope (that wish to insert several rules, possibly across many tables), or control-plane operations which call several ioctls in sequence, it will be worthwhile to support rollback if any requested operation fails. Implementing this logic on an as-needed basis would be error-prone, repetitive, and make it easier to fail while rolling back.

This is an open design question, in that:

• Scoping these internally within an individual ioctl would not be too difficult, and can be mostly hidden from API consumers.
• In the general case however, we also need to handle the fact that external clients like omicron will inevitably want to perform a list of operations with rollback semantics. We'd need then to expose transaction start/end as ioctls, and think about how existing request bodies should carry transaction IDs or similar state.
• The semantics of rule removal will likely need to change, at least while in a transaction context. Rules removed within a transaction need to be soft-removed, otherwise they may fail to be re-added on rollback.
• Is there a point in future where we might want, e,.g., operations on layers to have similar functionality?