[WFCORE-3185] Run parallel boot tasks in coarser grained chunks

[bstansberry]

https://issues.jboss.org/browse/WFCORE-3185

Instead of doing parallel boot with 1 task per extension (during extension initialization) and then 1 per subsystem (during subsystem op handling) this instead groups work into coarser grained chunks, with the number of chunks based on the number of available processors. Default setting is 1 subsystem chunk per processor, and 2 extension chunks per processor. This can be tweaked via unsupported system properties, which only exist to allow us WildFly devs to experiment with different values and on different types of systems.

On my 4-5 year old laptop this results in 8 chunks for subsystem work and 16 for extensions.

The number of threads used will be 2x the number of subsystem chunks, as the subsystem work needs separate chunks for Stage.MODEL vs Stage.RUNTIME, and the MODEL tasks block waiting for the overall boot op (and hence the RUNTIME tasks) to complete. So, 16 threads. This 2x behavior is partly why by default I use 2x the # of extension chunks as subsystem ones -- the threads will be started regardless, so using them for extension work incurs no additional cost for starting up threads. Also, quite a lot of classloading/IO may be involved in extension initialization (for example ideally all the extension's management integration classes would be loaded then.)

Testing over the summer showed no noticeable increase or decrease in boot time from this on my system. The number of threads used is much lower though, which is the point. With existing code booting WildFly's standalone-full-ha.xml results in spawning 72 threads vs the 16 here. (Note that disabling parallel boot altogether slowed down boot by about 400ms on my machine.)

[ropalka]

I had a quick look. Decreasing number of threads during the boot sequence is very good step forward.

[bstansberry]

retest this please