Tracking this count leads to some weird edge cases that we have to reason about, such as the following:

Update collection A, which already has a metadata entry stored in the fast count collection
When flushing we write to the fast count collection with the update for A's size and count
This write calls into the collection write path and sets the dirty flag for the metadata for the fast count collection to true, even though the size and count for the fast count collection has not changed and is in sync with the on-disk value
We try to create an empty diff (following SERVER-117656, we shouldn't actually write with an empty diff)

As part of this ticket we should also define the behavior for untracked collections (like the fast count collection itself) - that is, what the expected behavior should be if we try to call count on an untracked collection. Right now we return an empty (0,0) size and count entry, but we should explicitly fall back to performing a collection scan in these cases.