Akka.Remote + ForkJoinExecutor dispatcher configuration changes

[Aaronontheweb]

close #4589

Made it so ThreadPoolConfig properly factors in parallelism-factor now.

Adjusted default Akka.Remote dispatcher to use correct factors.

Going to benchmark this now and then provide updates.

[Aaronontheweb]

Before

ProcessorCount:                    16                
ClockSpeed:                        0 MHZ             
Actor Count:                       32                
Messages sent/received per client: 200000  (2e5)     
Is Server GC:                      True              
                                                     
Num clients, Total [msg], Msgs/sec, Total [ms]       
         1,  200000,     68705,    2911.78           
         5, 1000000,    191682,    5217.18           
        10, 2000000,    195332,   10239.85           
        15, 3000000,    193499,   15504.07           
        20, 4000000,    192725,   20755.96           
        25, 5000000,    192493,   25975.75           
        30, 6000000,    191102,   31397.05           
Done..                                               

[Aaronontheweb]

After

ProcessorCount:                    16
ClockSpeed:                        0 MHZ
Actor Count:                       32
Messages sent/received per client: 200000  (2e5)
Is Server GC:                      True

Num clients, Total [msg], Msgs/sec, Total [ms]
         1,  200000,      2075,   96421.61
         5, 1000000,    183925,    5437.79
        10, 2000000,    183756,   10884.77
        15, 3000000,    181775,   16504.60
        20, 4000000,    180890,   22113.51
        25, 5000000,    180506,   27700.41
        30, 6000000,    179528,   33421.46

Significant drop in performance due to decreased dispatcher throughput and higher CPU contention pressure.

I think the root issue is that:

• DotNetty allocates a large amount of threads as-is, and increasing the number of threads available to the remote dispatcher increased contention. More resources were consumed as a result of idle CPU.
• The drop in dispatcher throughput is disastrous for classic Akka.Remoting currently - the remoting pipeline passes through a single actor and dropping the dispatcher throughput completely kills it. This may not be the case with Artery or with the transport that @to11mtm is working on here: Streams TCP Transport with Hand-Written Protobuf Deserialization #4594

Going to slap a "do not merge" label on this PR for now. Needs more time to cook.

Worth noting though: the changes in #4511 had virtually no impact on Akka.Remote performance.

[Aaronontheweb]

Superseded by many other changes.