Issue #5486 PropertyFileLoginModule retains PropertyUserStores

[janbartel]

Closes #5486

In pursuing the original problem, which was that the PropertyFileLoginModule ignored the hotReload setting option for PropertyUserStores, I've realized there was a bigger problem, which is that the PropertyFileLoginModule was retaining instances of the PropertyUserStore in a static map and never removing them. Thus, the map would remain populated across restarts, possibly even pinning a classloader.

This fix ensures the the map of PropertyUserStores is retained on an instance of the JAASLoginService instead, and is cleared whenever the login service is stopped.

A few other code cleanups along the way, and added extra tests.

[lachlan-roberts]

Seems to be some test failures, so maybe it needs a merge from 9.4.x.

[lachlan-roberts]

This seems like an unusual way to share the LoginService with the LoginModule.
Would it be better to do this with a Callback instead? similar how we would use ServletRequestCallback.

[janbartel]

The problem is that we allow the user to supply their own CallbackHandler class, which might not know anything about the special jetty Callbacks, therefore couldn't supply a value for the JAASLoginService.

[lachlan-roberts]

Yeah that seems strange to me, how would you ever use ServletRequestCallback or RequestParameterCallback inside a login module because they only ever get set on the DefaultCallbackHandler? Seems like using this would also just break if they supplied a custom CallbackHandler.

[gregw]

LGTM.
If the threadlocal is a problem we could use it only as a fallback if the callbackhandler is not a type we know.... but that feels like complexity we don't need if the threadlocal works.