[db] turn @sunshowers' limit-reached query into a reusable thing

[hawkw]

This commit factors out the main logic of @sunshowers' DataStore::check_blueprint_limit_reached query into a reusable query fragment, because I wanted to use a similar query in my implementation of #9384 and felt this was nicer than copying and pasting it, even if it took much more fighting with Diesel than just copying it would have.

Fixes #10896

[hawkw]

I'm putting this up for review now so that I can get @sunshowers' opinion on it: in particular, I'm considering changing it a bit more so that check_if_limit_reached_async takes a TransactionRetryHelper rather than a db connection, so that the abstraction can also abstract over the need to run the ALLOW_FULL_TABLE_SCAN_SQL first, as well as abstracting over the reason we consider it okay to do that. What do you think?

[hawkw]

I'm putting this up for review now so that I can get @sunshowers' opinion on it: in particular, I'm considering changing it a bit more so that check_if_limit_reached_async takes a TransactionRetryHelper rather than a db connection, so that the abstraction can also abstract over the need to run the ALLOW_FULL_TABLE_SCAN_SQL first, as well as abstracting over the reason we consider it okay to do that. What do you think?

@smklein et al, Rain said they have a moderate preference for leaving this as-is and keeping the query composable with other stuff that might want to run in the same transaction, even if it comes at the cost of requiring the user to have to remember they must ALLOW_FULL_TABLE_SCANS_SQL in order to not have it fail at runtime. But, we'd both love to get your opinion on that.

[hawkw]

I'm putting this up for review now so that I can get @sunshowers' opinion on it: in particular, I'm considering changing it a bit more so that check_if_limit_reached_async takes a TransactionRetryHelper rather than a db connection, so that the abstraction can also abstract over the need to run the ALLOW_FULL_TABLE_SCAN_SQL first, as well as abstracting over the reason we consider it okay to do that. What do you think?

@smklein et al, Rain said they have a moderate preference for leaving this as-is and keeping the query composable with other stuff that might want to run in the same transaction, even if it comes at the cost of requiring the user to have to remember they must ALLOW_FULL_TABLE_SCANS_SQL in order to not have it fail at runtime. But, we'd both love to get your opinion on that.

Update on this: now that I have started actually trying to write code that uses this thing, I have quickly realized that it is quite valuable to be able to run the limit-reached check query in a transaction that does other things --- I would like to be able to delete records only if over the limit, and that is, of course, hard to do outside a transaction (or CTE) which ensures that the check if over the limit and the deletion of the records occurs atomically. So, I think I'm going to leave this PR as it is.

[sunshowers]

Thanks!