Two fixes here:

1. We were not consistently dispatching the unitTestSubscriptionPoolWorkComplete
   notification, because when _clearSubscriptionPoolWork was called from dealloc
   we had already cleared our delegate list before the call.  This was the
   proximate cause of the random failure: when we got deallocated before the
   work item for our subscription pool work got dequeued, we would end up with
   subscriptionRunningCount too high (since it would increment on enqueue but we
   would miss the decrement.

2. The fake device is not consistent about whether it actually dispatches the
   unitTestSubscriptionPoolDequeue notification: usually it does not (because it
   was dealloced before that happened), but sometimes it does.  When it does, we
   were ending up with more dequeue notifications than expected in the test. The
   fix for this is to not track the dequeue/complete bits in the test for the
   fake device at all.

Fixes project-chip#38797

Two fixes here:

1. We were not consistently dispatching the unitTestSubscriptionPoolWorkComplete
   notification, because when _clearSubscriptionPoolWork was called from dealloc
   we had already cleared our delegate list before the call.  This was the
   proximate cause of the random failure: when we got deallocated before the
   work item for our subscription pool work got dequeued, we would end up with
   subscriptionRunningCount too high (since it would increment on enqueue but we
   would miss the decrement.

2. The fake device is not consistent about whether it actually dispatches the
   unitTestSubscriptionPoolDequeue notification: usually it does not (because it
   was dealloced before that happened), but sometimes it does.  When it does, we
   were ending up with more dequeue notifications than expected in the test. The
   fix for this is to not track the dequeue/complete bits in the test for the
   fake device at all.

Fixes project-chip#38797

…ol (#38803)

Two fixes here:

1. We were not consistently dispatching the unitTestSubscriptionPoolWorkComplete
   notification, because when _clearSubscriptionPoolWork was called from dealloc
   we had already cleared our delegate list before the call.  This was the
   proximate cause of the random failure: when we got deallocated before the
   work item for our subscription pool work got dequeued, we would end up with
   subscriptionRunningCount too high (since it would increment on enqueue but we
   would miss the decrement.

2. The fake device is not consistent about whether it actually dispatches the
   unitTestSubscriptionPoolDequeue notification: usually it does not (because it
   was dealloced before that happened), but sometimes it does.  When it does, we
   were ending up with more dequeue notifications than expected in the test. The
   fix for this is to not track the dequeue/complete bits in the test for the
   fake device at all.

Fixes #38797

…ol (project-chip#38803)

Two fixes here:

1. We were not consistently dispatching the unitTestSubscriptionPoolWorkComplete
   notification, because when _clearSubscriptionPoolWork was called from dealloc
   we had already cleared our delegate list before the call.  This was the
   proximate cause of the random failure: when we got deallocated before the
   work item for our subscription pool work got dequeued, we would end up with
   subscriptionRunningCount too high (since it would increment on enqueue but we
   would miss the decrement.

2. The fake device is not consistent about whether it actually dispatches the
   unitTestSubscriptionPoolDequeue notification: usually it does not (because it
   was dealloced before that happened), but sometimes it does.  When it does, we
   were ending up with more dequeue notifications than expected in the test. The
   fix for this is to not track the dequeue/complete bits in the test for the
   fake device at all.

Fixes project-chip#38797