[nexus] Add virtual provisioning idempotency tests, prevent underflow

[smklein]

Builds on #5081 and #5089 , but more out of convenience than necessity.

Summary

This PR attempts to validate that, for the "virtual provisioning collection {insert, delete}" operations, they are idempotent. Currently, our usage of max_instance_gen only partially prevents updates during instance provisioning deletions:

• If max_instance_gen is smaller than the observed instance generation number...
• ... we avoid deleting the virtual_provisioning_resource record (which is great)
• ... but we still decrement the virtual_provisioning_collection values (which is really not great).

This basically means that we can "only cause the project/silo/fleet usage values to decrement arbitrarily, with no other changes". This has been, mechanically, the root cause of our observed underflows (e.g, #5525).

Details of this change

• All the changes in nexus/db-queries/src/db/datastore/virtual_provisioning_collection.rs are tests validating idempotency of these operations.
• All the changes in nexus/db-queries/src/db/queries/virtual_provisioning_collection_update.rs are actually changes to the query which change functionality. The objective of these changes is to preserve idempotency of the newly added tests, and to prevent undercounting of virtual provisioning resources. If these changes are reverted, the newly added tests start failing, showing a lack of coverage.

[smklein]

I basically tried to move all the validation of the state_generation into this boolean do_update? subquery, then re-use that check in multiple spots where we can perform updates below.

[smklein]

The problem here is that (before this PR) do_update could be "true", but the state generation could be below our "max", which would result in that buggy partial deletion state.

Now:

• If do_update is true, we really believe we should perform the insertion/deletion
• If that's the case, we can use it as the deciding factor to both delete the virtual_provisioning_resource and decrement the usage in the virtual_provisioning_collection table

[gjcolombo]

Thanks for doing this! LGTM as far as the use of the do_update clause goes--this is more or less the fix I had in mind for #5042, which issue I think this will resolve.

I know the conversion to raw SQL is part of a different PR, but I also looked at the entire expected query output in virtual_provisioning_collection_update_delete_instance.sql and the structure there also looks right to me (I didn't check the parameter ordering too closely though).