Fix silent consumer death after broker events and connection recovery

[jkamleh]

Summary

Fixes an issue where consumers silently stop receiving messages from RabbitMQ after a random period (hours to days), requiring a service restart to recover.

Root cause appears to be a combination of bugs in the consumer lifecycle:

• No ConsumerCancelled/Shutdown handlers - when the broker cancels a consumer (HA failover, queue policy change, memory alarm), the consumer goes deaf with zero errors logged
• Stale channel after connection recovery - AutomaticRecoveryEnabled recovers the connection, but the cached _channel field still points to the old dead channel. No RecoverySucceeded handler existed to invalidate it
• Race condition in RestartIn() - the _timer.Enabled guard was not atomic, allowing concurrent threads to either both enter or both skip the restart path
• Unhandled exception in error path - BasicNack after a channel close threw an exception that was caught by the outer handler, which called RestartIn() again, but the timer was already running so the second call was a no-op. The consumer never restarted
• _stopping guard on event handlers - ConsumerCancelled/Shutdown events also fire during intentional Stop()/Dispose(), which would schedule an unwanted restart. A volatile flag distinguishes intentional teardown from broker-initiated disconnects

All fixes are internal to BasicRabbitService and QueueService. No changes to public interfaces, method signatures, configuration models, or enum values.

Test plan

• Verify full solution builds with no new errors
• Run existing test suite - 41/46 pass, same 5 pre-existing test isolation failures as original code (All tests pass individually; failures are caused by shared queue state between tests in the same run)
• Integration test: kill the RabbitMQ connection mid-consume and verify the consumer recovers automatically
  • Tested, killed the RabbitMQ connection via management API mid-consume and confirmed the consumer detected the drop, recovered, and resumed processing messages automatically, see screenshot:
  
• Integration test: delete and recreate the queue while a consumer is active and verify it restarts
  • Tested using example Subscriber.Service locally, deleted MyQueue locally got: Consumer cancelled by broker on queue MyQueue, tags: Subscriber. Scheduling restart.
  • Recreated queue, got: Consumer started on queue MyQueue
• Verify PublishService still works (uses original single-arg base constructor)
  • The PublishWithExchange, PublishWithProperties, PublishDirect, PublishEmptyMessage, PublishWithException and ToExchange tests all use PublishService and they all passed in our test run.