We have reports of datasets that get re-harvested with an extra `1`
in the URL. We have confirmed these reports.
It seems the harvest is doing the best it can to diagnose if
this is a new dataset or not;
but still failing in some circumstances.
This probably won't fix the bug; however it will mitigate it.
By hopefully running through the datasets removal first,
if the spatial harvester is essentially doing a "delete and add"
when it should be replacing, then the name of the new dataset
won't collide with the one that is marked for deletion
but still in the system.

If the harvest is managing the datasets in ckan, it seems that the
harvest source should be the "source of truth".
If this is the case, we shouldn't need "revive" capability of soft
removing packages/datasets in ckan. I propose to actually purge
the dataset within ckan.
Since it's difficult/nearly impossible to track these files without a
unique id, sometimes the harvester will delete and create a new item if
the waf or files change in any way. This would keep that behind the
scenes, and allow the end user to get to the same dataset at the old URL