Replicator integration with corto_select

[SanderMertens]

This issue is meant to capture commits and comments about integration between replicators and the corto_select call, so to not pollute issue #416.

[SanderMertens]

For each scope that is traversed by corto_select, it will check whether there are replicators that have registered with the scope. When a replicator is found, corto_select will invoke the request call of the replicator. The signature of request looks like this:

resultIter request(string parent, string expr)

The request method returns an iterator, which must at least contain next and hasNext callbacks. It may optionally also implement a release callback, which will be invoked when corto_select finishes iterating over the iterator, and allows for resource cleanup. As a result of #416 a corto_waitNext callback will eventually be available as well for controlling blocking behavior.

The parent argument contains the query path relative to the point where the replicator registered itself with the store. The expr argument contains a filter expression that follows fnmatch conventions.

The corto_select call will always filter the returned results by the replicator with this expression, thus a replicator does not have to filter itself. In some cases however, efficiencies can be gained when the replicator is aware of the expression- for example when doing a request to a remote machine an expression can limit the amount of data that is returned.

The replicator is expected to return elements of the type corto_result which contains a name, type and parent member. The name member is the name of the represented object. The type member must be the full path to the type of the represented object. The parent member must be a path relative to where the replicator registered itself with a scope.

This approach assumes that objects can be mounted on different mount points across different stores, but types (or rather: packages) always need to be in consistent locations.

The corto_select call will return elements with parent paths relative to what was provided as scope argument. This means that in some cases corto_select will do translations on returned results in order to return consistent results.

[SanderMertens]

If the parent argument in the request call ends with /*, the replicator is expected to return a tree of objects.