Detach fields in-order after consensus match

[manopapad]

No description provided.

[lightsighter]

So if I'm understanding this correctly, this version effectively does a consensus match to see which fields to recycle, and when it does that, then it see which fields can be recycled across all the shards, and it does the ordered detach at that point right before it recycles the IDs in the same way across all the shards. If that's accurate, it definitely seems better than doing the unordered detach operations.

One obvious idea to play around with here is whether we can pipeline this process. For example, if we shrunk the number of allocations between consensus match calls down to 16 (from the default 32?), but then instead of blocking to wait for the result, we just saved the result for the next 16 allocation calls to be done, and then look at the result of the previous consensus match to see if we can recycle any of those fields? Seems like that might be better than exposing the latency of the consensus match. We could also probably make the pipeline three stages deep:

1. Start consensus match
2. Check consensus match and issue ordered deletions for any fields
3. Check futures that are done and finalize actually remove references to their external resources