fix(bigtable/bttest): make table gc release memory

[philpearl]

How does the emulator store rows?
Each table in emulator contains a Btree which stores the rows:

type table struct {
	rows        *btree.BTree             // indexed by row key
        ....
}

Each object in this btree is of type row. A row has a families map. A family has a cells map keyed by column name

A sample row would be:

{
	families: {
		"col-family-1": {
			cells: {
				"col-1": [{
					"value": "val-1"
				}],
				"col-2": [{
					"value": "val-2"
				}],
				"col-3": [{
					"value": "val-3"
				}]
			},
		},
		"col-family-2": ....
	}
}

Many fields have not been shown in above sample for brevity.

Now, when cells col-1 and col-2 are deleted, the emulator just sets "col-1" and "col-2" to empty array i.e. the row becomes:

{
	families: {
		"col-family-1": {
			cells: {
				"col-1": [],
				"col-2": [],
				"col-3": [{
					"value": "val-3"
				}]
			},
		},
		"col-family-2": ....
	}
}

In this PR, this behaviour is being changed to remove the key itself i.e. the row will become:

{
	families: {
		"col-family-1": {
			cells: {
				"col-3": [{
					"value": "val-3"
				}]
			},
		},
		"col-family-2": ....
	}
}

Similarly, when all the families are deleted, the empty row will be deleted as well.

Closes: #6102

Description by PR and issue original author:
We had a problem where we were unable to run the BigTable emulator for extended periods in dev environments without giving it huge amounts of RAM, even if we had quite aggressive GC policies applied to the tables. This fixes that by making GC in the emulator actually delete empty rows and columns.

[philpearl]

Ah, actually, scratch that. It's still not safe. I'm not convinced it was safe before as GC was changing the cell slices, but this has certainly made it more obviously unsafe.

The easy option would be to hold the write lock over the GC cycle, whether it changes or not. A harder option would be to do the whole thing in two phases

[philpearl]

Ah, no, wrong again. I think this version is good. The row lock protects us.

[philpearl]

Wrong a third time! We need to re-check the rows as we delete them with a lock held. It could be that cells have been added to the row in the meantime. Fix incoming

[tritone]

This looks fine to me now. @kolea2 @crwilcox could you take a look?

[crwilcox]

This looks good to me also. I have asked some other folks that are more familiar with the emulator to take a look also, in case there is a hidden gotcha.

[philpearl]

Any chance of getting this merged?

[jimfulton]

LGTM, but needs at least a basic test.

[philpearl]

@jimfulton do you have any suggestions about what the test would look like and what it would test? Presumably there are already tests that the GC operates correctly in terms of what's visible in the database. There are already tests that catch issues with --race (I know because I broke them!). Are you suggesting a test that counts memory allocations?

[bhshkh]

Reviewing

[bhshkh]

The changes LGTM

I've raised an issue. #6102. I'm afraid I didn't understand what type of test jim fulton was expecting and he didn't answer my query.

You can add a test with simple gc rule such as maxNumVersions and verify that empty rows, cells, cell families did get deleted.

[bhshkh]

Added the tests