desired in the vinterfaces table, in the interface_state table.
Desired bandwidth that has not been reserved is indicated as a
negative value in vinterfaces; when we update interface_state we also
update the negative value in vinterfaces (atomically in the same
query, I am getting good at that multi table stuff).

You would think this would be simple eh? Well, just you think again.

Swap modify (update) has to be considered. When doing a swapmod, the
old version of vinterfaces is in the backup file, and the new version
is in the vinterfaces table. But we have to know the old reserved
bandwidth so we know the proper amount to reserve (in other words,
release the old reserved bandwidth from the previous table). We waited
till now to do it, since we do not want to get into a situation where
we release the BW, assign fails, and then someone else got that BW,
cause then we are screwed and have to swap out the experiment.
Unfriendly. So, the update changes happen all at once (tables locked).

So that's it, right? Only for a babe in the woods that you are.

We also have to consider rollback when swapmod fails and we want to
restore the old experiment state. This can happen either before we
have reserved the new bandwidth, or afterwards. Each is a different
situation, and the only way to know what has happened is to update the
backup table file in the first part of update so that later rollback
knows. Yep, I change the backed up vinterfaces table. Twice in fact,
the second time after the rollback finishes. Gack.

Note that rollback can suffer from the problem I was trying to avoid
in update; losing the reserved bandwidth to someone else and having to
swap out. Nothing to do about that.