findEpersonByNetId should stop searching when it finds an eperson

[kosarko]

https://github.com/dataquest-dev/DSpace/blob/c25374e0b2ff6e9f8aba429c8372a466affbcad5/dspace-api/src/main/java/org/dspace/authenticate/clarin/ClarinShibAuthentication.java#L1321-L1345

The for cycle always runs through all possibilities, there's no break or return inside. It should stop when it finds an eperson based on some netid header.

We've seen broken logins, the idp is sending both an eppn and persistent-id, the database contains the eppn as the netid, but based on the logs any further login attempt fails as it tries to create a new user based on the persistent-id

2024-11-21 11:00:50,022 ERROR unknown unknown org.dspace.authenticate.clarin.ClarinShibAuthentication @ Unable to parse schema and field string from name: 'cn'
2024-11-21 11:00:50,022 INFO  unknown unknown org.dspace.authenticate.clarin.ClarinShibAuthentication @ Unable to identify EPerson based upon Shibboleth netid header: 'persistent-id'='REDACTED[https://cas.cuni.cz/idp/shibboleth]'.
2024-11-21 11:00:50,022 INFO  unknown unknown org.dspace.authenticate.clarin.ClarinShibAuthentication @ Identified EPerson based upon Shibboleth email header: 'mail'='[email protected]'.
2024-11-21 11:00:50,022 ERROR unknown unknown org.dspace.authenticate.clarin.ClarinShibAuthentication @ The identified EPerson based upon Shibboleth email header, 'mail'='[email protected]', is locked to another netid: '[email protected][https://cas.cuni.cz/idp/shibboleth]'. This might be a possible hacking attempt to steal another users credentials. If the user's netid has changed you will need to manually change it to the correct value or unset it in the database.                                                                2024-11-21 11:00:50,022 INFO  unknown unknown org.dspace.app.rest.security.EPersonRestAuthenticationProvider @ anonymous::failed_login:email=null, result=4