Make client classes accessible to proxy/federated stores

[d21211122]

When deploying proxy or federated stores, you need to include the Operations, Functions and Data classes of the remote stores to enable the operations to be processed. If stores made a client jar available to clients, this mechanism could be automated, with stores able to dynamically update themselves as remote dependencies change or new stores are added.

[n3101]

@GCHQDeveloper404 Is this issue still relevant in the light of your v2/maestro changes? I.e. do I close it; push it to after v2.0 or what?

[n3101]

@GCHQDev404 Is this issue still relevant in the light of your v2/maestro changes? I.e. do I close it; push it to after v2.0 or what?

[n3101]

After discussion, it appears this may partly have been covered by the maestro changes, so after those have been merged (alpha-4) test this one again as part of alpha-5 work and identify what remains to do.

[t92549]

Is this made redundant by https://github.com/gchq/Gaffer/issues/2823?

[GCHQDev404]

Yes.

But some examples to think about with #2823 vs this ticket.

example 1) FederatedStore receives an nonstandard operation, it simply forwards the operation (which was not able to be json deserialised) to remote graphs, which is good. example 2) FederatedStore does know about the nonstandard operations and has a local handler/hook to do something interesting with it, which is good. example 3) same as example 2 but someone updates the operation, now it can't be handled anymore. should it error or forward the operation.

So a choice needs to be made between the 2 or an alternative to both #2057 and #2823 is #2487

[GCHQDev404]

This will be pushed back to after v2 and as a high priority because this will make management of multiple graphs easier.