Remove deprecated SecurityManager, AccessController, SecurityException #184

[jbescos]

https://github.com/eclipse-ee4j/angus-mail/issues/184

Do we remove this?: https://github.com/eclipse-ee4j/angus-mail/blob/eca8e08baa56a83ab68ae3faaca25d8ca3c0e5ee/mailhandler/src/main/java/org/eclipse/angus/mail/util/logging/LogManagerProperties.java#L246

[jmehrens]

#184

Do we remove this?:

https://github.com/eclipse-ee4j/angus-mail/blob/eca8e08baa56a83ab68ae3faaca25d8ca3c0e5ee/mailhandler/src/main/java/org/eclipse/angus/mail/util/logging/LogManagerProperties.java#L246

There are 2 options:

1. Delete body except for the call to removing null handler from global. This makes the checks contextual to jdk.
2. Delete the method completely and not enforce checks at all on old JDK.

[jmehrens]

@jbescos For logging-mailhandler, in the last release I tried to make the security manager work operable on old JDKs and forward compatible with JDK25 to deal with missing, hostile, methods and classes. What you have coded up would have been the patch I would code for when Angus-Mail requires JDK25.

That said, the simplicity of not dealing with SecurityManager is nice.

Also SecurityException is not deprecated yet which is why I have certain catches. Especially for overridable methods like in java.lang.Thread which could unconditionally throw SecurityException without a SecurityManager.

[jbescos]

OK, then we are good in Angus Mail for the time being and we don't need this PR so far. My understanding is, the main requirement is to not depend on SecurityManager, and we don't depend on it currently.

CC @lukasj . I think he wanted to get rid of AccessController and SecurityExceptions too.

[jmehrens]

There still might be work to do in Angus Mail to align with JakartaEE. For logging-mailhandler, I try to support a wide range of JDKs down to min JDK. I'll try to do a proper review today.