Stop syncing H2.0 to CKAN

[tdlowden]

Feature/what we're after

Get rid of CKAN as part of the harvest process and sync to a Dataset table in Postgres instead.

Anticipated/hypothesized benefits

• We no longer have to keep a catalog-next service alive
• We can drop the materialized view of latest Datasets and take care of syncing from HarvestRecords into Dataset ourselves

Measurements/metrics

• Harvests are running in dev and the Catalog-next service is not running

References/background

• At the end of our harvest, we do some work to synchronize the results of that harvest into CKAN.
• Some of that work is very useful, including the formation of ckan_name and geospatial management.
• We want to keep those important pieces and replace the CKAN "sync" process with an update to an actual Postgres table called Dataset that essentially holds the latest version of a particular HarvestRecord instance.

[jbrown-xentity]

Please note that some of the current logic to sync to CKAN may not be removed entirely.
For example, for spatial search we need standardization of the location value into some type of geometry format ideal for openSearch (geoJSON, or something else)? Since we do this for SOLR, we'll want to wrap that back into the postgreSQL table for later ingestion into openSearch. This is already handled for CKAN/SOLR. We just need to make sure we don't throw the baby out with the bathwater here, and keep the important standardization where we can.

Also note that for performance reasons we may not have things "live synced", either at initial harvest or at harvest completion for openSearch, but the necessary information of the object does need to be stored back into PostgreSQL for later ingestion.

[FuhuXia]

@jbrown-xentity I am taking bbox -> geoJSON translation out of ckan utils and make it into harvest utils. so that part is fine.

One thing needs to be taken care is the uniqueness of ckan_name (i.e. dataset slug). the current logic still relies on ckan sync error to be notified that there is a name conflict. we should change the logic so that it is harvest's responsibility to make the slug unique.

[rshewitt]

this is the follow up ticket for creating and writing to the "dataset" table ticket