Workflow / update notification level based on user profile when cancelling a submission

[josegar74]

A workflow metadata submission is cancelled with these 2 actions:

• cancel working copy (from editor) --> should be notified the reviewer.
• rejection (from reviewer) --> should be notified the editor.

Currently, by default the editor is notified: https://github.com/geonetwork/core-geonetwork/blob/111a1d7f79fe23b5663e727aeaf126277576fe89/web/src/main/webapp/WEB-INF/classes/setup/sql/data/data-db-default.sql#L527

It can be changed the notification in the database to notify the reviewer, but in both types of cancellation is notified the same type of user, what doesn't seem correct.

This change adapts the notification depending on the user profile that cancels a submission:

• cancel working copy (from editor) --> reviewer is notified
• rejection (from reviewer) --> editor is notified.

Test case:

1. Create a user with profile Editor and another user with profile Reviewer.
2. Configure in the settings the mail settings and activate the metadata workflow.
3. Login with the editor user, create a metadata and submit it for review
4. With the editor user, cancel the submission:

• Without the change: the editor user gets the mail notification.
• With the change: the reviewer gets the mail notification.

5. With the editor user, submit again the metadata.
6. Login with the reviewer user and reject the submission:

• Without the change: the editor user gets the mail notification. (it's ok as by default the editor is notified)
• With the change: the editor gets the mail notification.

Checklist

• [X] I have read the contribution guidelines
• [X] Pull request provided for main branch, backports managed with label
• [ ] Good housekeeping of code, cleaning up comments, tests, and documentation
• [X] Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• [X] Clean commit messages, longer verbose messages are encouraged
• [ ] API Changes are identified in commit messages
• [ ] Testing provided for features or enhancements using automatic tests
• [ ] User documentation provided for new features or enhancements in manual
• [ ] Build documentation provided for development instructions in README.md files
• [ ] Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation