Issue title: Only allow  sormas users with  "SORMAS_STATS_VIEW" right to authenticate with sormas-stats kaycloak client
 Issue body: <!--
If you've never submitted an issue to the SORMAS repository before or this is your first time using this template, please read the Contributing guidelines (https://github.com/hzi-braunschweig/SORMAS-Project/blob/development/docs/CONTRIBUTING.md) for an explanation of the information we need you to provide. You don't have to remove this comment or any other comment from this issue as they will automatically be hidden.
-->
### Situation Description
<!-- Mandatory -->
#8927 allows all authenticated sormas users to access sormas-stats.  Sormas-stats contain analytics, thus applicable to only sormas users who are responsible to produce epidemiological reports.

### Feature Description
<!-- Mandatory -->
- only active users with with SORMAS_STATS_VIEW right  should access sormas-stats, ie SORMAS_STATS_VIEW==t and ACTIVE ==t,  then begin authentication
### Possible Alternatives
<!-- Optional -->

### Additional Information
<!-- Optional -->

 Comments: 
 Comment 0: @fhauptmann @jwijffels @vidi42 
This is just in preparation for the discussion
 Comment 1: @MartinWahnschaffe  I just had a discussion with  @jwijffels @bernardsilenou  and I found a potential issue with Keycloak/OIDC which we need to consider.
 Comment 2: I don't think that we should add a user right for an external system to SORMAS itself.

The user rights are only meant to define what the user is allowed to do within SORMAS itself and thus are not synced to keycloak.

Defining whether a keycloak user can access other systems like sormas-stats, should be handled in keycloak itself, not SORMAS.
 Comment 3: > I don't think that we should add a user right for an external system to SORMAS itself.

The shiny app at https://github.com/hzi-braunschweig/SORMAS-Stats-next-gen has similar read rights as `sormas_user` to the SORMAS DB, making it a sormas user.

> The user rights are only meant to define what the user is allowed to do within SORMAS itself and thus are not synced to keycloak.

Why is the information which user is still active or not _not_ synched back to Keycloak? What is the purpose of Keycloak then? 

- I thought Keycloak is perfect as an OIDC connector. 
- Is there a plan to have SORMAS itself be an OIDC provider instead or are third-party systems not allowed?
 Comment 4: 
> I don't think that we should add a user right for an external system to SORMAS itself.
> 
I have changed the issue to use `statistics_access`,  an existing sormas right.  In addition, sormas-satas is not a stand-alone external system, it fully depends on sormas and is used by sormas users only. 
> The user rights are only meant to define what the user is allowed to do within SORMAS itself and thus are not synced to keycloak.
> 
This is true for an independent system, but since specific sormas users are the ones to access sormas-stats, then we think it would be easy to just transfer the right that we need from sormas to keylock. If not then the admin would need to manage users in keylock which is not realistic for a system that has many users. 
> Defining whether a keycloak user can access other systems like sormas-stats, should be handled in keycloak itself, not SORMAS.

This is true, however, admins creating users in sormas would not want to to also go to keycloack to manage those same users. In practice, its one person doing the job. So the goal is to transfer few existing users attributes ( sattistics_view and status) to keycloack and keyclaock would do as you suggested.
hope what we though is realistic


 Comment 5: > The shiny app at https://github.com/hzi-braunschweig/SORMAS-Stats-next-gen has similar read rights as `sormas_user` to the SORMAS DB, making it a sormas user.

The users management in SORMAS is independent from the database user - in fact by default there is only one database user used by the sormas backend, but one "SORMAS user" per real-world user. From my understanding this issue is about real-world users.

> Why is the information which user is still active or not _not_ synched back to Keycloak? What is the purpose of Keycloak then?
>     * I thought Keycloak is perfect as an OIDC connector.
>     * Is there a plan to have SORMAS itself be an OIDC provider instead or are third-party systems not allowed?

Keycloak is currently only used for authentication, not for authorization. But this is not put into stone - there was simply no use case to sync user rights to keycloak when they are supposed to be managed in sormas anyway.

Coming back to my argument to not put sormas-stats related user rights into SORMAS, by explaining it with another example: 
Let's say the SORMAS users should be able to access climedo with the same account via keycloak. In this case it would also be very strange to manage the climedo user rights from within sormas. Instead you would expect that keycloak only handles authentication for both systems or that all user rights for both systems are handled in keycloak.

> I have changed the issue to use `statistics_access`, an existing sormas right. In addition, sormas-satas is not a stand-alone external system, it fully depends on sormas and is used by sormas users only.

Yes, I think that makes a lot of sense. In theory we could run into problems when the user right is dropped or renamed in SORMAS, but as you rightly say, sormas-stats is not a stand-alone external system and already highly depends on SORMAS anyway.

So the todo that needs to be done here is to implement a mechanism that syncs the sormas user rights to keycloak so they can be used for sormas stats. This mechanism somehow has to handle the new configurable user roles as-well (#4461).
 Comment 6: > So the todo that needs to be done here is to implement a mechanism that syncs the sormas user rights to keycloak so they can be used for sormas stats.

Looking forward to see this happening.
 Comment 7: https://github.com/hzi-braunschweig/SORMAS-Project/commit/f8dbcec9a7f28a62ceb05ccc2eb26a9052f8ee14 changed the validation for URLs (`geocodingUrl`, `mapTilersUrl`) with placeholders that now breaks deployment.

```
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean: java.lang.IllegalArgumentException: Invalid URLs for which HTTPS is enforced in property file:
        [https://sg.geodatenzentrum.de/gdz_geokodierung_bund__<uuid_removed>/geosearch.json?query=${street}+${houseNumber},${postalCode}+${city}&filter=typ:haus&count1](https://sg.geodatenzentrum.de/gdz_geokodierung_bund__%3Cuuid_removed%3E/geosearch.json?query=$%7Bstreet%7D+$%7BhouseNumber%7D,$%7BpostalCode%7D+$%7Bcity%7D&filter=typ:haus&count1)
        at com.sun.ejb.containers.EJBContainerTransactionManager.checkExceptionClientTx(EJBContainerTransactionManager.java:615)
        at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:485)
        at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4601)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2134)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2104)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:90)
at com.sun.proxy.$Proxy940.validateConfigUrls(Unknown Source)
at de.symeda.sormas.backend.common.__EJB31_Generated__ConfigFacadeEjb$ConfigFacadeEjbLocal__Intf____Bean__.validateConfigUrls(Unknown Source)
at de.symeda.sormas.backend.common.StartupShutdownService.startup(StartupShutdownService.java:252)
```
 Comment 8: @StefanKock @MartinWahnschaffe 
No bug here I just forgot to hit the user sync button in the UI, so changes were not synced 
 Comment 9: Reopening the ticket as updating the user roles is not happening in keyckloack. It has to be done explicitly.
{'source': 'GithubIssues', 'repo_name_with_owner': 'hzi-braunschweig/SORMAS-Project', 'issue_id': 1227158133, 'repo_stars': 290.0}