Metadata publication notifications / allow to configure the mail format

[josegar74]

This pull request allows to configure the mail format (html or text) for the metadata publication notifications in https://github.com/geonetwork/core-geonetwork/compare/main...GeoCat:core-geonetwork:44-metadatapublicationmails-configure-format?expand=1#diff-5c9ae0ecadc341dc6ccdf055599053c721d9eb3cb8e6d633e5c995a7346d7312R80

Default configuration sends html format as previously to this change.

In some systems the following mail messages are customised to contain text values:

core-geonetwork/core/src/test/resources/org/fao/geonet/api/Messages.properties

Lines 140 to 144 in 6dbaa47

	metadata_published_text=The following records have been processed:\n\
	<ul>%s</ul>
	metadata_published_record_text=<li>The metadata <a href="{{link}}">{{index:resourceTitleObject}}</a> has been published.</li>
	metadata_unpublished_record_text=<li>The metadata <a href="{{link}}">{{index:resourceTitleObject}}</a> has been unpublished.</li>
	metadata_approved_published_record_text=<li>The metadata <a href="{{link}}">{{index:resourceTitleObject}}</a> has been published as a new version.</li>

Requiring to be sent as text, so can be processed to trigger some automated processes.

---

An alternative that was evaluated was to analyse the mail message to check if contains html tags with Jsoup, but the changes done in #8044 requires the format in the constructor, previous to do any processing of the mail templates / content.

core-geonetwork/core/src/main/java/org/fao/geonet/util/LocalizedEmail.java

Line 50 in 6dbaa47

public LocalizedEmail(Boolean isHtml) {

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• 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

[jodygarnett]

While this is not ideal it is functional. I have documented the new setting (and the multi-lingual settings that you linked to).