GetWalks does not work with FederatedOperations

[t92549]

Describe the bug
Since 2.0.0, we prefer users to use a FederatedOperation rather than the deprecated graphIds option. However, this does not work as an operation within GetWalks. This is problematic as it is undocumented and relies on users using a deprecated option.

To Reproduce
Steps to reproduce the behaviour:

1. GetWalks(input=1, operations=[FederatedOperation(operation=GetElements(), graphIds=[A])])
2. This operation will not build

Expected behaviour
It should work fine with both the graphIds option and a FederatedOperation.

Stack trace and errors

ConnectionError: HTTP error 500 : {"statusCode":500,"status":"Internal Server Error","simpleMessage":"Operation chain is invalid. Validation errors: \nNo hops were provided. A hop is a GetElements operation that selects at least 1 edge group."}

Additional context
Looking at the stack trace, this seems related to this check inside the GetWalks validation:

Gaffer/core/operation/src/main/java/uk/gov/gchq/gaffer/operation/impl/GetWalks.java

Lines 163 to 174 in dde023f

	if (op instanceof While) {
	hops += (((While) op).getMaxRepeats() * getNumberOfGetEdgeOperations(((While) op).getOperation()));
	} else if (op instanceof Operations) {
	hops += getNumberOfGetEdgeOperations(((Operations<?>) op).getOperations());
	} else if (op instanceof GetElements) {
	final GetElements getElements = (GetElements) op;
	if (null != getElements.getView() && getElements.getView().hasEdges()) {
	hops += 1;
	}
	}
	return hops;
	}

Platform

• Gaffer Version: [e.g. 2.0.0]

[GCHQDeveloper314]

Isn't it possible to workaround this issue by placing the GetWalks inside the FederatedOperation? At least for where a single graph is queried? I don't see an easy solution otherwise. It works with the deprecated option because the federation is applied at a different level.

FederatedOperation is not a core operation, so it can't be referenced from GetWalks. I think it would be reasonable if GetWalks only supported the operations provided in that code snippet. Adding special handling for FederatedOperation into the operation probably isn't practical as it would require refactoring the FederatedOperation to make use of some kind of intermediate core class - to hold the information about the inner GetElements.

Assuming that hops value of 0 is not useful, I would suggest changing GetWalks to provide an error explaining which Operations are meaningful to use with it.

Alternatively, this could be fixed by introducing a special FederatedGetWalks operation.

[t92549]

Isn't it possible to workaround this issue by placing the GetWalks inside the FederatedOperation? At least for where a single graph is queried?

This would result in the whole GetWalks going to one subgraph, whereas instead we want to walk across multiple subgraphs.

FederatedOperation is not a core operation, so it can't be referenced from GetWalks

This is correct, eventually though I realised that FederatedOperation could implement the Operations interface (and probably should have all along). In my solution I just added it to get these tests passing, but I think that FederatedOperation should be refactored to make proper use of the Operations interface: #3078.