Push deletion of empty files out to the gc process.

Make selection of files to gc a little more robust.
However, this is buggy in two places:
1. We update the left and right pointers as deletion is taking place. This is fine, but it then means that in find_files_to_gc, we walk over the table, and will find the links don't work - cue badmatch and explosion. I really don't want to try and reason about concurrent deletions to the file_summary_ets_table, so I think this is going to necessitate a msg back from the gc to the msg_store indicating that the deletion is done and to tidy up any left over mess in the file summary table.
2. In contains or read or remove, if we find the file we want to access is locked, we add_to_pending_gc_completion. But of course now the file can be locked because it's about to be deleted, rather than GC'd, and currently (though see above), there is no such msg back from the gc process to the msg_store to indicate when a file has been deleted. This could mean actions could build up in the pending queue and never be run. This then raises the question of how this pending queue should be structured. Maybe we should have a mapping from File -> [Action]. Then when either a gc or deletion confirmation comes in, we know which actions to free up.

0 files changed, 0 insertions, 0 deletions