Pipelining split and import

[YuJuncen]

Feature Request

After #266, our main progress of restoring is pipelined, but at the split-scatter and import stage, it's sequential, which will waste many time during restoring.

Describe your feature request related problem:

N/A

Describe the feature you'd like:

Pipelining split and import.

Describe alternatives you've considered:

N/A

Teachability, Documentation, Adoption, Migration Strategy:

Unfortunately, we must change the interface of BatchSender to make it able to run asynchronously, instead of returning a nil which presenting all tables are restored, every time a table has been restored(or, some error happens), we should emit them to a sink:

// TableSink is a sink for asynchronous task.
type TableSink interface {
	EmitTable(utils.Table)
	EmitError(error)
}

// BatchSender is the abstract of how the batcher send a batch. 
type BatchSender interface {
	// RestoreBatch will send the restore request.
	RestoreBatch(ctx context.Context, ranges []rtree.Range, rewriteRules *RewriteRules, sink TableSink)
	Close()
}

Fortunately, the batcher itself can run asynchronously, so we don't need modify it greatly.

[YuJuncen]

BTW, we can introduce a more intelligent "split" method, that is, for each range (i.e. file), we can 'collect' them until they are greater than 96MB, then we can split ranges by each 96MB-chunks, so we can reduce the region number after splitting.

Maybe we can do this with help of the range tree.