Improve hook searching

[mcweba]

With the current implementation, hooks (in the storage) can be searched by calling the configured hook uri. For example:

GET /gateleen/server/hooks/v1/registrations/
{
	"registrations": ["listeners/", "routes/"]
}

GET /gateleen/server/hooks/v1/registrations/routes/
{
	"routes": [
	  "+gateleen+server+push+v2+internal+publish+_hooks+route",
	  "+gateleen+server+push+v2+internal+subscribe+_hooks+route",
	  "+gateleen+server+push+v2+internal+tokenInfo+_hooks+route",
	  "+gateleen+server+push+v2+internal+unsubscribe+_hooks+route"
	]
}

GET /gateleen/server/hooks/v1/registrations/listeners/
{
	"listeners": [
	  "http+gateleen-demo-dummyEvent-hook+gateleen+demo+v1+delivery+dummy+events",
	  "http+gateleen-demo-deliveryEvent-hook+gateleen+demo+v1+delivery+events",
	  "http+gateleen-demo-testEvent-hook+gateleen+demo+v1+delivery+test+events",
	  "http+push_v2+e39daf509c+gateleen+demo+v1+date+20200415+zips+999997+tours"
	]
}

Hooks can only be found based on the names and encoded urls shown in the examples above.

Looking at a specific hook, there are more information which could be useful to search for:

GET /gateleen/server/hooks/v1/registrations/routes/+nemo+server+push+v2+internal+subscribe+_hooks+route
{
	"requesturl": "/gateleen/server/push/v2/internal/subscribe/_hooks/route",
	"expirationTime": "2020-04-16T12:30:37.665+02:00",
	"hook": {
		"methods": ["POST"],
		"destination": "https://iid.googleapis.com/iid/v1:batchAdd",
		"headers": [{
			"header": "Content-Type",
			"value": "application/json"
		}, {
			"header": "access_token_auth",
			"value": "true"
		}]
	}
}

Properties like requesturl and destination could be good candidates to search for.

Hook search API
Adopt the HookHandler class (or a suitable other handler) to handle hook searching requests.
These requests could look something like this:

POST /gateleen/server/hooks/v1/registrations/routes/
Body:
{
	"destination": "^(.*)batchAdd$"
}

Response:
{
	"routes": [
	  "+gateleen+server+push+v2+internal+subscribe+_hooks+route"
	]
}

[lbovet]

Wouldn't it be simpler to just add a query parameter to the routes/listeners resources?
Like GET /gateleen/server/hooks/v1/registrations/routes/?q=batchAdd
The only meaningful field to search in is the destination. We can do a full-text search on it.
This way we can easily use that in the browser for a quick search and also build a beautiful UI search field with suggestions as you type.

[mcweba]

I thought about query parameters too but avoided them because regex patterns could not be defined. There could be more fields to search for like for example x-queue-headers which are set or something else. We could in fact just provide a single query parameter (q) and search over all fields in the resource with a full-text search. WDYT?

[lbovet]

I fear a bit of overengineering. Regexp are not necessary, I think.
I don't see a use case for searching in headers as well. I propose to keep searching only in destination. We can still extend this later (e.g. using a additonal parameter fullText).
As far as I understand, this is just something to help devs and ops.