Added a facility get modules that supports a given interface in the same branch okapi-337-multiple-interfaces

Implemented and in branch okapi-337-multiple-interfaces

There are two questions to be asked?

1. Should we allow multiple modules to be registered for a tenant with same interface?

2. If the answer is "yes", then how should we point/address individual modules with that interface?

For 1. Allowing that does not change existing behavior.. Okapi by default will use "static" linking and allow exactly one version of some module with an interface registered for a tenant. The dynamic linking puts a burden to the client. No question about it. Note that we already use this for system interfaces.. tenant initialization and tenant permissions. You can call it fan-out or event driven. but it is something we already use.

For 2.. IMHO, using a Header rather than rewriting paths is much simpler.. Suppose a module's HTTP client is is driven by the RAML definition (RMB supports it), then if the path to be used does NOT conform to the definition (/Eg.. a client would have to use {/codex.hammer} rather than {/codex}. For this reason, I think it is much cleaner to have the interface reference/pointer in the header. Only the HTTP client will have to set the header.. It will be gone as soon as it arrives to the module behind the interface.

This mechanism also allows for "optional" modules. For example, a UI component can discover modules as they see fit.

If we don't do this somehow, there's no events or fan-out in our system.. So we would eventually have to offer another mechanism.

The problem of knowing if an interface named "codex" is conforming to a spec (say RAML) has not changed by this.. We still have that issue. We also have a great problem of feeding JSON schemas between modules using an interface and another one using it. Perhaps we can be more explicit about schemas in the module descriptors themselves. What's happening now is that we put a lot of "shared" stuff in the raml Git repo. It will become harder to maintain over time if schemas are modified a lot.

My understanding coming out of the Dublin meeting matches Vince's – that `pathAlias` would be added to the existing ModuleDescriptor. In the case of multiple instances, the ModuleDescriptor of each interface is going to need to change anyway (because of the fact that multiple interfaces cannot be registered on the same path). Because of that, the definitive path remains in `pathPattern` and the new functionality – the `pathAlias` – is in a new, optional setting.

As I understand the above – the discovery of implementations of a given interface (through the "enumeration" interface) would be pushed to the client. This is contrary to the current design pattern in Okapi (the so-called "dependency injection") where the client is unaware of implementations, but only of interfaces.

Currently, we do not define interfaces outside of and share them across ModuleDescriptors, IMHO we would need to do that to make the multiple instances functionality useful – otherwise we could not bother with keeping the interfaces aligned but simply add a capability to query a tag or label in Okapi.

Also, what in terms of enforcing that the versions of "aliased" interfaces are aligned?