Catalog search provider

[zoran995]

What this PR does

Fixes #

Move the catalogue search provider from SearchBarModel to the Catalog class. I always felt that the catalogue search provider doesn't belong in SearchBarModel, but at the time I was writing it, I wasn't aware of Catalog, so it stayed in the model.

Test me

How should reviewers test this? (Hint: If you want to provide a test catalog item, create a Gist of its catalog JSON, add its url and your branch name to this url: http://ci.terria.io/<branch name>/#clean&<raw url of your gist> , and then paste that in the body of this PR)

Checklist

• There are unit tests to verify my changes are correct or unit tests aren't applicable (if so, write quick reason why unit tests don't exist)
• I've updated relevant documentation in doc/.
• I've updated CHANGES.md with what I changed.
• I've provided instructions in the PR description on how to test this PR.

[na9da]

Hi @zoran995 - looks great.

One small thing I noticed is we do a cast here to access a property not part of the interface:

terriajs/lib/ReactViews/ExplorerWindow/Tabs/DataCatalogTab.tsx

Lines 57 to 62 in 2d6577e

	debounceDuration={
	terria.catalogReferencesLoaded
	? (
	searchState.catalogSearchProvider as CatalogSearchProvider
	).debounceDurationOnceLoaded
	: DEBOUNCE_INTERVAL

We should maybe make it part of the interface or traits instead.

[na9da]

Suggestion: I know we have done this elsewhere in the past but it might be a good idea to stick with standard Constructor parameters for models? Using custom constructor parameters is fine if the model is always initialised manually but if at some point we do automatic initialisation from some config, it could create problems.

One other pattern to make creating the instance easier would be to define a static method like CatalogSearchProvider.fromOptions({minCharacters})

[na9da]

Can this be undefined if always intialised in constructor?