Monitor threadpool should be configurable

[akafredperry]

Based on the logs from the BDD tests, the threadpool used for dispatching monitor notifcations seems overly large by default. Here is some sample log

[pool-2-thread-7] INFO org.atsign.cucumber.steps.AtClientContext - @gary received deleteNotification : {metadata={sharedKeyEnc=null, pubKeyCS=null, d
[pool-2-thread-3] INFO org.atsign.cucumber.steps.AtClientContext - @gary received updateNotification : {metadata={sharedKeyEnc=null, pubKeyCS=null, d
[pool-2-thread-10] INFO org.atsign.cucumber.steps.AtClientContext - @gary received decryptedUpdateNotification : {metadata={sharedKeyEnc=null, pubKey
[pool-2-thread-1] INFO org.atsign.cucumber.steps.AtClientContext - @gary received sharedKeyNotification : {metadata={sharedKeyEnc=null, pubKeyCS=null
[pool-2-thread-9] INFO org.atsign.cucumber.steps.AtClientContext - @gary received sharedKeyNotification : {metadata={sharedKeyEnc=null, pubKeyCS=null
[pool-2-thread-3] INFO org.atsign.cucumber.steps.AtClientContext - @gary received deleteNotification : {metadata={sharedKeyEnc=null, pubKeyCS=null, d

With multiple threads the ordering would be non-deterministic which might be an issue
e

Describe the solution you'd like

I think it should default to single thread
The thread factory should set a user friendly name
Support the ability to override the threadfactory

Describe alternatives you've considered

No response

Additional context

No response

[gkc]

sgtm