sql: DROP of a large table causes server to become unresponsive.

[mrtracy]

When calling DROP TABLE on a table with a large number of rows, the cockroach server tends to become completely unresponsive: its memory usage skyrockets, and incoming requests are no longer serviced.

This was discovered when using the block writer example. The block writer program writes a large number of rows to a single table "blocks"; when the program starts, it calls DROP TABLE IF EXISTS blocks during initialization; thus, if the block writer is allowed to run for some time, and then is restarted, it results in a DROP TABLE over a large dataset, exposing this bug.

[tamird]

This should go away when async stuff is in. cc @vivekmenezes

[mberhault]

#2003 (perform drop in background) would also help.

[tbg]

Those changes would circumvent the issue, but we should make sure that a large DeleteRange is performant still. Just replace the DROP by an allowed variation of `DeleteRange(KeyMin,KeyMax)`.

[tamird]

@andreimatei @tschottdorf @vivekmenezes we have a plethora of issues tracking this - can one of you coalesce?

[andreimatei]

same as #7499