Be more intelligent about when to GC

[msiebuhr]

Spun off from #12

Thinking it over, it should have some way of ensuring we'll do a GC on/after an upload. Current logic is to check if (quota < size + newly-uploaded-item) { gc() }, which means we'll do a GC on most uploads when we're hovering around the quota.

• Run GC periodically (either timer or every X requests/connections)
• Over-GC (say, 10% or just remove the oldest entry from every bucket)
• Have a lock/queue, so we don't over-schedule GC's (we can upload small items a lot faster than we can GC them)
• More fine-grained locking so GC doesn't block new uploads (goes with locked GC'ing, so we don't have something looking at files while another is deleting them...)

[msiebuhr]

Wrt. queueing GC, it should be possible to indicate that we need a GC for some reason or other.

We could start GCs (like we do now) and then have some flag/run-bit aborting if a GC is already running (or queued to run immediately).

Alternatively, have a go-routine run GCs in a loop, blocking on a channel or sync.Cond (and quitting on shutdown-signal) and then send on the cannel / cond.Signal() whenever we need to run a GC.

Using channels, roughly:

runGc := make(chan bool, 1)
func startGCloop() {
    for {
        // Change to select {} over runGc + timer for regular GCs + shutdown-signal
        <- runGc
        // Do GC
    }
}

func doGc() {
    select {
        case runGc <- true:
        default:
    }
}

go startGCloop()