Stop using backend to delete cascade nodes

[stellanl]

Part of #2694.

[stellanl]

/app_worker/dataprocessor?action=deleteCascadeNodes
is called from three places:
com.gallatinsystems.survey.dao.CascadeNodeDao.deleteRecursive()
com.gallatinsystems.survey.dao.CascadeResourceDao.delete()
org.waterforpeople.mapping.app.web.DataProcessorRestServlet.scheduleCascadeNodeDeletion()

Deleting tree nodes is done in a nicely recursive way.
A fundamental problem is that the timing it is not predictable; the cascade may split into an arbitrary number of branches at any level. Call that number n.
The current algorithm fetches all nodes at the current level (1 datastore lookup) and then for each of them checks if it has children (n lookups). Parents are recursively scheduled on the backend task queue. Those without children (0-100% of n) are deleted (1 mass datastore deletion).
I assume the time taken is dominated by datastore ops, making the worst case (all children) be f(2n+1)

Unless the task was sent to the backend "just in case", this must be what can overrun the task queue's 600s limit. I see two ways to cut it down:

1. Schedule all deletions on the task queue, regardless of leaf or not. Then there are always just 2 datastore ops per task. WIll take longer.
2. Fetch the entire cascade into memory and calculate the list of nodes to be deleted. Only 2 datastore ops in total, but the memory required may be excessive.

[stellanl]

After a few tests I believe nothing needs to be optimised. I deleted a huge cascade, and none of the tasks took>300ms (the last ones that should have had most of the leaves). Most were around 100ms.
I also created a single-level cascade with 1000 leaves. Deleting that node took just 250ms.
To be clear, though, this was when alone on the akvoflowsandbox instance.