The 'compact' operation sequentially copies all the records in the namespace into a new extent. Since this operation creates no new data,
the standard extent logarithmic sizing should not apply; the algorithm is only to accomodate data growth.
Instead, we will start back at the beginning with the smallest extent size. This will allow for freed-extent reuse over multiple compacts.
Note that the only way to have freed extents in a database is to run compact, so the first time you run it, there will always be new extents created.
Subsequent compacts will potentially reuse the freed extents.
The compact speed unit test's time comparison seemed backwards to me, so I fixed it and made it a real assert.
I also bumped up the padding in the padding test so that it would trigger a new extent and thus have a material increase in the storage size.
of every request but intra request. if a request will run for a very long time this is bad.
probably not for backporting -- might be nuances need to smoke for a while
also some yield code cleaning, really just making it easier to read.
