Make TIME aware ConeSearch services discoverable

[molinaro-m]

Being the TIME query parameter optional, it is not clear how a client can discover the services that support it. This should be a matter of resource registration, but it could be also conveyed in a metadata only response for the service.

This metadata response can be achieved using a MAXREC=0 call to the service:

• if it returns an error it means the client deals with a ConeSearch-1.03 service
• otherwise the metadata would show whether TIME is available as a param for query or not

[molinaro-m]

Taking the liberty of quoting an email from @msdemlei :

As to noting TIME support: Well, we already have param in
vs:ParamHTTP (DaCHS, for instance, has declared its SCS parameters in
this way forever).  Sure, you need to query the Registry to figure
out parameters in this way, but while doing discovery that's not a
problem.

When talking to a service a client has run into in another way, I'd
say MAXREC=0 metadata discovery, SSAP-style, ought to do the trick.

It looks only enforcing on the registration side will be needed, plus a proper SSAP-style specification within the ConeSearch document, since DALI is quite flexible and not completely defined on MAXREC=0.

[molinaro-m]

Freely copying from another email from @msdemlei :

+1 for just referencing DALI, plus regulations on how the input
parameters should be represented.  For that second part, I'm a bit
undecided: We could copy what SIAP and SSAP do -- works, but feels a
bit stuffy --, or we could borrow from Datalink and have the input
parameters in a dedicated GROUP of a separate, non-result, RESOURCE
(which is a bit less hacky, but of course different from S*AP)

where the +1 is about not modifying the behaviour of MAXREC in DALI.