Refactor Permission and PermissionCollection classes

[pfirmstone]

Does anyone really require Serializable Permission's?

If anyone wants to serialize a Permission or PermissionCollection, it's easy enough to serialize a list of strings, then parse those strings back into Permission objects.

It has a significant negative impact on Permission implementation code, the Permission spec states Permission's should be immutable, but often they are lazily initialized, in ConcurrentPolicyFile, each Permission must be initialized following construction to ensure safe publication, however we have no control over safe publication when a Permission is used by client code in permission checks.

jdk-with-authorization/src/java.base/share/classes/au/zeus/jdk/authorization/policy/PermissionGrant.java

Line 125 in 8dcb3da

* Ensure any action fields are populated before

[pfirmstone]

Refactoring Permission and PermissionCollection classes:

1. Add generics and for loop support.
2. Remove Serialization Support
3. Prevent finalizer attacks by ensuring any exceptions are thrown prior to calling superclass constructor during construction.
4. Fix race conditions, make fields final where possible, or volatile to ensure visibility.
5. Permission::getName and Permission::getActions methods are used by PermissionComparator to avoid calling equals methods (which can cause DNS Lookup on SocketPermission and file system access on FilePermission). Reconsider lazy loading of Permission implementations, considering that both CombinerSecurityManager and ConcurrentPolicyFile have to call Permission::getActions to ensure safe publication.