MergeSchema is ignoring SchemaExceptions

[t92549]

Describe the bug
When the MergeSchema class applies the Schema.BaseBuilder.merge function, it catches SchemaExceptions. This is because it will retry while ignoring vertex serialisers if the error is to do with vertex serialisers:

Gaffer/store-implementation/federated-store/src/main/java/uk/gov/gchq/gaffer/federatedstore/util/MergeSchema.java

Lines 56 to 65 in e90fba0

	try {
	mergeSchema.merge(new Schema.Builder(update).vertexSerialiser(vertexSerialiser).build());
	} catch (final SchemaException e) {
	if (e.getMessage().contains(Schema.UNABLE_TO_MERGE_SCHEMAS_CONFLICT_WITH_VERTEX_SERIALISER_OPTIONS_ARE)) {
	LOGGER.error(String.format("Caught SchemaException, attempting to re-merge but without vertex serialisers. Error message:%s", e.getMessage()));
	//Clashing Vertex Serialiser is possibly a recoverable state, continue without using Vertex Serialisers, retain this state.
	context.put(WIPE_VERTEX_SERIALISERS, true);
	mergeSchema.merge(new Schema.Builder(update).vertexSerialiser(null).build());
	mergeSchema.vertexSerialiser(null);
	}

However, if the SchemaException is unrelated to vertex serialisers, I would expect the exception to still be thrown:

if (e.getMessage().contains(Schema.UNABLE_TO_MERGE_SCHEMAS_CONFLICT_WITH_VERTEX_SERIALISER_OPTIONS_ARE)) {
    // handle the vertex serialiser issue...
} else {
    // throw other types of SchemaException
    throw e
}

This is not the case.

Additional context
If you simply add this else block in, tests will start to fail. These tests are FederatedStoreVisibilityTest (issue: #1834) and FederatedStoreSchemaOverlapTest (issue: #2767). These tests were added as part of Gaffer 2 development to codify the new FederatedStore behaviour, however, we did not realise this behaviour was happening as a result of a bug.

Suggested fix
MergeSchema should be fixed and extended to manage all types of SchemaException.
When a SchemaException happens due to conflicting visibility property names, this can probably be intentionally ignored with a warning message.
When a SchemaException happens due to conflicting types for the same property in the same group across two subgraphs, things are more complicated. Perhaps, if the type definitions are the same the error can be ignored, and if not they can be de-duplicated.
This will likely need work on Schema.BaseBuilder.validateSharedGroupsAreCompatible

[GCHQDeveloper314]

If the concatenate merge function is used for a schema instead, then I assume this bug will not be seen?

[t92549]

@GCHQDeveloper314 Correct, but it will not merge the schemas. Pre-2.0, the schemas were merged. Forcing concatenation of the schemas is untested behaviour, it may effect how the other merge functions work when performing a GetElements for example