EE support for LIMIT PARTITION ROWS EXECUTE DELETE...

Adds a couple new methods to `PersistentTable`: `hasPurgeFragment` and `getPurgeFragmentId`.  The insert executor will request the `VoltDBEngine` to execute the purge fragment if the table is at its row limit.

My current thinking is that the purge fragment for a table should be cached like any other fragment.  The purge fragment might be executed often, or very infrequently, so our LRU caches seem well-suited to this.  This approach also minimizes changes in the back end, as well as changes to catalog.  (Currently we represent expression trees in the catalog, but there is no precedent for a complete fragment.)

It's still unclear to me how we might handle the problem of mapping a table to its purge fragment id, especially since the purge fragment id might change when it's removed and then re-cached.


In real world, does the PURGE_FRAGMENT_ID will be changed for a certain table? I totally understand your concern about the LRU cached plan for this fragId. It is not a special fragment to the engine and got evicted from the cached plan in EE, I guess it has to fetch the plan for Java, right ? If so, I think it's all right to be a normal fragment id.