Move login-ui Service classes to Javaconfig

[Kehrlann]

Context

We are moving out of XML config and into java config.

This moves *Service used by login-ui out of XML config, and can be used as a blueprint to move some config out of XML.

Below are a few notable changes to the configuration.

Configuration properties

Example: SmtpConfigurationProperties.

Avoid @Value, prefer @ConfigurationProperties classes which allow for easily following where they are actually used. Default values can be provided. Validation can be applied. Avoid SpEL expressions where possible, prefer Java code, either in constructors or in bean methodes.

For configuration properties, when possible, prefer immutable records.

Code-independent beans

Examples: EmailChangeEmailService, EmailAccountCreationService, etc.

Any bean that:

1. Has a unique implementation
2. Does not have conditions to decide whether it should be present or not
3. Does not have configuration variants ("use this or that param, based on some condition")

can be provided with a stereotype annotation, such as @Component or @Service. When they are not used anywhere in XML config, they do not need to be named.

Conditional and code-dependent beans

Examples: JavaMailSender, MessageService.

Some beans are configuration-dependent. They require some code to be correctly created, and may be conditional on some application properties ("only create a NotificationsService when there is a notifications.url property"). They are typically interfaces, that have multiple implementations.

Those beans need to be provided in @Bean functions in @Configuration classes.

Typically, one implementation is the default, and other is what happens when certain conditions are met. A way to achieve this in javaconfig is to annotation the configuration-dependent bean with @Primary, and it will override the default bean. Spring Framework 6.2 / Boot 3.4 will provide an @Fallback annotation to achieve the same result.

Keep the code minimum in @Bean methods when possible, and rely on declarative configuration instead.

Reference data

With beans moved out of XML, reference data, such as util:map id="notifications", needs to be moved to java (in this case, in a helper static method, notifications()).

In this particular case we chose functions to avoid a nested Map<String, Map<String, String>>: it makes in XML or other text-based data representation, but less in Java.