Use a virtual thread factory

[robotdan]

Switch to using virtual threads. This will allow us to push much harder on a single system.

Example with 100 threads for login.

Login
- 100 p-threads
                            Total duration:	114054 ms (~114 s)
                            Total count:		100000
                            Avg. latency:		2.052 ms
                            Avg. success:		876.778 per second

- 100 v-threads
                            Total duration:	44351 ms (~44 s)
                            Total count:		100000
                            Avg. latency:		42.931 ms
                            Avg. success:		2254.741 per second

This should let us push FusionAuth a lot harder- at least without having to spin up a bunch of compute to get enough threads to really push it.

The difference is the most evident with a lot of threads because we end up just spending most of the time context switching when we run fusionauth-app and this load test on the same host. FusionAuth is likely then getting starved for CPU time if the load test harness spins up that many platform threads.

This result is the Login API w/ a load factor of 1 on the password hash, so this simulates removing CPU as the bottleneck.

[bhalsey]

is this supposed to be using newVirtualThreadPerTaskExecutor()?

[robotdan]

I didn't do that on purpose, but I suppose I could.

The goal was to keep the simulated number of workers. In practice, perhaps it is the same since we spin up the number of workers explicitly. Maybe 6 of one half dozen of the other? Perhaps the only benefit of using a pool with the virtual workers is if we want to make the pool smaller than the number of workers which we never do...

So... maybe I should just remove it. I'll take another look.

[bhalsey]

I'm not seeing how this code is using virtual threads

[robotdan]

I swapped it out and removed my comment.