Enabling parallel bundle activation for ssl-1.0 feature causes build failures on z/os

Referring to #10078. I am trying to enable parallel bundle activation for ssl-1.0 but it causes test failures on the z/os FAT. Since mpMetrics depends on restHandler-1.0 which depends on some security features, including ssl-1.0, this would need to be parallel bundle activated at some point . Parallel bundle activation (PBA) of security features:

ssl-1.0 was PBA but reverted because it was causing build failures on z/os: https://wasrtc.hursley.ibm.com:9443/jazz/web/projects/WS-CD#action=com.ibm.team.workitem.viewWorkItem&id=267935
Jared Anderson said the security components have some weird dependencies set up and that will need to be reworked before security bundles can be enabled for parallel activation. Parallel bundle activation:
start-phase: Liberty defines start phases which control the order bundles start.
If start-phase not specified, start-phase = CONTAINER
if a feature is marked for PBA then feature's bundles are started in parallel with other bundles in that feature, and other features that are also PBA for a specific start-phase.
If you depend on feature that is not PBA, then the dependant feature bundles will not activate in parallel. Instead they will be activated sequentially after all the parallel activated bundles for the start-phase have completely activated. Problems with enabling PBA on SSL-1.0 on z/os
Gary DeVal's team was working to speed up server startup, and so they were paying very close attention to the timing of messages in the logs reporting progress in various stages of startup
They were watching to see how well the multiple available hardware threads were being used during startup - as much as possible, they want all the threads to be busy doing required startup work, rather than e.g. one thread busy and the others idle
when they tried ssl-1.0 parallel activation, Gary started observing some variability in the time required to get to the "ready to run" message ... when he dug into the logs looking for the source of the variability, it turned out to be related to part of the ssl startup, related to creating the key
whenever that activity kicked off, the other startup threads were apparently blocked, so no progress was made in their tasks
the keystore creation seemed to be the "blocking" activity
if keystone creation began BEFORE rest of startup work, other threads would be delayed (because of keystone creation) and "ready to run" message is much later
if keystore creation started AFTER threads completed their work "ready to run" would not be delayed Requirements:
Need to enable PBA for ssl-1.0 Failures in FAT with enabling PBA ssl-1.0:
com.ibm.ws.jbatch.security.zfat.BatchSyncToThreadJMSTest
com.ibm.ws.jbatch.wola_zfat

Reproducing the issue: Add WLP-Activation-Type: parallel to ssl-1.0 feature file Run build with properties: spawn.zos=true

OpenLiberty / open-liberty

Enabling parallel bundle activation for ssl-1.0 feature causes build failures on z/os #10614