x1158 Support specifying existing external names in file block reg

[khelwood]

The manual block reg request has an "existing" boolean field to specify that the tissue external name is already in use and that's OK. The file block reg now accepts an additional "existingExternalNames" parameter listing external names that are known and accepted to be existing tissues.

How it already works with manual block reg:

• User requests a registration
• Core finds that some external names listed are already in use
• Core sends a response to the client listing "clashes"
• Client checks for clashes in the response
• Client informs the user and offers to register them anyway (as existing tissues)
• If the user accepts, the client sets the "existing" field inside the request and sends it back to the core

How it should work in file block reg:

• User submits a block reg file
• Core finds that some external names listed are already in use
• Core sends a response to the client listing "clashes"
• Required: Client checks for clashes in the response
• Required: Client informs the user and offers to register them anyway
• Required: If the user accepts, the client resends the file with an additional post parameter listing the known existing tissue names

NB The client should also check for clashes in other file registration modes, and at least report it as a problem to the user (matching the behaviour in manual registration).

[khelwood]

@sabrine33 It's here: RegisterServiceImp. This bit is existing behaviour, not part of the pull request. In the graphql schema here

[sabrine33]

@khelwood , I am not sure about that, as testing with the client with some existing ids, I did not receive any. My guess, is to add it within the output object here: https://github.com/sanger/stan-core/blob/c7daf3a275703f8859973907a3f8fec9e7494b79/src/main/java/uk/ac/sanger/sccp/stan/RegistrationFileController.java#L83

[khelwood]

@sabrine33 You may be right. I'll check it and fix it. :+1:

[khelwood]

@sabrine33 OK I've added the external name for clashes into the response. Thanks for catching that :+1: