bigtable/bttest: ModifyColumnFamilies should be synchronous and blocking

[dragonsinth]

Expected behavior

In production bigtable, ModifyColumnFamilies is a slow-running operation. Once complete, any dropped column families will no longer be returned by row scans. bigtable emulator should replicate this behavior. An example flow:

• ModifyColumnFamilies to remove column family "foo"
• ModifyColumnFamilies to add column family "foo" back
• RowScan does not return any data from the "foo" column family.

Tested vs. production bigtable.

Actual behavior

bttest's ModifyColumnFamilies returns quickly and leaves the actual data purge up to background garbage collection. Subsequent row scans can return data that doesn't exist. If a column family is re-created in the interim, the data is never purged. An example flow:

• ModifyColumnFamilies to remove column family "foo"
• ModifyColumnFamilies to add column family "foo" back
• RowScan returns old data from before the modify calls

[dragonsinth]

#4096

[jimfulton]

@crwilcox It looks like this should be closed.

[dragonsinth]

Same comment: It's definitely fixed, but I'm not sure how things work regarding linking issues to particular releases; some projects don't close issues into a release happens.