FederatedStore Double Cache Collision Bug

[GCHQDev404]

Describe the bug
Having FederatedStore Rest service with no propterty gaffer.cache.service.name.suffix specified and then a addGraph for a second FederatedStore with no suffix, results in a Cache collision. Both graphs are the same. (Also a suffix could have been provided and be duplicated)

In a Graph as Service situation multiple user may add additional federated graph without a suffix and all have cache collision. This could expose inner graphs with weak/no security believing it was protected by the enclosing sub-federated graph. (equally suffix could have been provided and duplicated)

Rest FederatedStore{

    FedStoreA{
    owningUser=userA
    graphId = "FedFoo"
    suffix = "foo"
    cache = "FederatedCachefoo"
    graphs{
        graphAWithNoSecurityMapStore{}
    }
    }

    FedStoreB{
    owningUser=userB
    graphId = "CheatingGraph"
    suffix = "foo"
    cache = "FederatedCachefoo"
    graphs{
        graphAWithNoSecurityMapStore{} <---- exposed/stolen/duplicated
    }
    }

}

To Reproduce
Steps to reproduce the behavior:

Create FederatedStore Rest service with no specified suffix gaffer.cache.service.name.suffix in properties.
AddGraph FederatedStore with no specified suffix gaffer.cache.service.name.suffix in properties.
Run a FedereatedOperation{GetAllGraphIds} which goes to the subgraph.
subgraph return the graphId of itself because the two FederatedStore are the same due to a cache name collision.
Additional context
This maybe expected behaviour because the stores have been misconfigured to use the same cache.
But the possibly exploit to expose the contents of another FederatedStore in the same RestService seems incorrect.

No infinite loops should occur.

Possible Workarounds

Optional AddGraph Hooks to mitigate against the use of not providing a suffix
FederatedStore to mitigate against cache name collision in the same JVM, which does not effect load balancing of FederatedStore.

Impact

No one this is an Alpha 4 issue.

[GCHQDev404]

This may have all been fixed by the implementation of #2890

[GCHQDev404]

Accidental collision will be removed.

But if policy is required to not allow deliberate collisions then a custom hook or similar should be implemented to enforce policy.

Documents required.

[t92549]

Closed by #2902