fix(security): load the system account from DS activation, not Shiro onInit() (GOSS-025)

[craigpnnl]

Fixes the GOSS-025 bootstrap failure where SystemBasedRealm activates with an
empty account map, so the built-in system account cannot authenticate to the
broker.

Symptom

Failed to add Connection ... due to Realm [pnnl.goss.core.security.system.SystemBasedRealm@22587507]
was unable to find account data for the submitted AuthenticationToken
[org.apache.shiro.authc.UsernamePasswordToken - system, rememberMe=true].

WARN [pnnl.goss.core.server.impl.GridOpticsServer] - Error Connecting to ActiveMQ
  at pnnl.goss.core.server.impl.GridOpticsServer.start(GridOpticsServer.java:463)

Cascade: empty system realm -> ActiveMQ refuses the connection -> GridOpticsServer
service factory returns null -> LogManagerImpl cannot resolve ServerControl ->
FieldBusManagerImpl cannot resolve LogManager and bails. Reproduced 4 of 4 in a
local container stack, with the same realm instance empty throughout each run.

Root cause

SystemBasedRealm populated userMap only from onInit(), Shiro's Initializable
hook. Verified against the actual dependency (shiro-core 2.0.0, pnnl.goss.core/bnd.bnd:12):
onInit() is invoked from exactly one place, AuthenticatingRealm.init(), normally
driven by LifecycleUtils.init() from an ini or Spring bootstrap. No OSGi Declarative
Services path reaches it. RealmSecurityManager.setRealms() -> afterRealmsSet() only
calls setCacheManager and setEventBus. There are zero init() / LifecycleUtils /
Initializable call sites in goss-core.

The @Activate method, which DS does guarantee, only logged.

So the system realm's account map has been empty in every OSGi run since it was written.

Why this was not noticed until now

The message "unable to find account data for the submitted AuthenticationToken" occurs
in exactly one shiro-core class: ModularRealmAuthenticator.doSingleRealmAuthentication,
reached only when getRealms().size() == 1. When a second realm is registered,
doMultiRealmAuthentication runs under the default AtLeastOneSuccessfulStrategy and
PropertyBasedRealm authenticates the same system account from userfile.cfg.

The empty system realm was always masked by the property-file realm. An environment that
registered only the system realm removed the mask and exposed it.

This is not a regression in any recent release: SystemBasedRealm.java and
GridOpticsServer.java are byte-identical between v15.0.5 and v16.0.0.

Changes

• SystemBasedRealm: a single idempotent loadSystemAccount(). @Activate, @Modified,
  the SecurityConfig bind/unbind/updated callbacks, and onInit() all delegate to it,
  so no entry point is left broken. The map is cleared before rebuild, so a renamed
  manager user cannot leave the previous principal able to authenticate.
• The SecurityConfig field reference became a dynamic greedy method reference with
  unbind and updated. The credential lives in the pnnl.goss.security PID rather than
  this component's own PID, so @Modified alone never saw a pnnl.goss.security.cfg edit.
• Fail closed: a missing SecurityConfig, or a blank goss.system.manager or
  goss.system.manager.password, throws IllegalStateException naming the property and
  file. Thrown from @Activate this aborts DS activation, so the realm service is never
  published and the broker never connects against an empty realm. Previously this
  condition produced a silently empty realm.
• Activator.registerAllRealms() declines an empty realm set instead of throwing.
  Removing the last realm previously produced, on the shutdown path:
  java.lang.IllegalArgumentException: Realms collection argument cannot be empty
  at RealmSecurityManager.setRealms(RealmSecurityManager.java:80).

The permission string granted to the system account is unchanged.

Tests

Three new test classes, 19 new tests. RED before the fix included hasIdentifier("system")
false immediately after activate(), and the IllegalArgumentException above reproduced
from Activator.realmRemoved.

Assertions check field values rather than absence of a crash: primary principal, credential,
and getStringPermissions() matched exactly against the literal permission string, so a
future edit to the production grant fails the test. Descriptor-level assertions cover
activate, modified, configuration-policy=require, and configuration-pid, since those
are what the container actually invokes.

Result: 55 passed, 0 failed (baseline 36, all previously passing). Full ./gradlew build
succeeds. Two pre-existing build warnings are unrelated and unchanged.

Follow-ups, deliberately not addressed here

• The permission string queue:*,topic:*,temp-queue:*,fusion:*:read,fusion:*:write is
  passed as a single string to addStringPermission. WildcardPermission splits on :
  before ,, producing eight parts rather than the five permissions it reads as, so it
  likely does not grant what was intended. Preserved verbatim here because changing an
  authorization grant belongs in its own reviewed change.
• pnnl.goss.core.security.impl.SystemRealm appears to be dead code and hardcodes "*"
  against the literal key "system" regardless of the configured username.