Simplify locking logic in class `SqlTableChangeMonitor`

[JatinSanghvi]

This issue tracks the fix to address the code review comment in #226.

Make an issue to look into this please - at the very least I'd like to try and refactor this slightly to make this easier to understand. All this locking stuff I want to go over anyways since right now it seems kind of arbitrary where the locks are acquired/released which could easily lead to issues later on.

Originally posted by @Charles-Gagnon in #226 (comment)

[JatinSanghvi]

Did some analysis for this GitHub issue. Here were the findings:

1. The _rowsLock is correctly acquired and freed in all situations. In other words, there is no code path where the lock is getting re-acquired or not getting freed.

2. The lease-renewal loop involves a very small subset of functions. So, even if _rows, _state and _leaseRenewalCount variables are accessed in a couple of places, we only need to ensure those variables do not get into race condition with the subset of methods that get invoked inside lease-renewal loop.

3. I did not find a location where _rows can enter race condition (i.e., it gets updated inside one loop while it is being accessed or iterated over in the other loop), but the way these races are avoided seemed kind of convoluted to me. For example, it is always ensured that _rowsLock is acquired before changing _state from ProcessingChanges to CheckingForChanges but not the other way around. Since lease-renewal loop only renews leases if it can "acquire _rowsLock and find that _state is set to ProcessingChanges", that makes sure that change-consumption loop cannot call ClearRowsAsync and set the _state back to CheckingForChanges while the leases are being renewed.

[Charles-Gagnon]

Thanks for the investigation @JatinSanghvi , so it sounds like there's some room for cleaning this up but it's not a critical issue we need to fix - did I understand that correctly?

Was this something you think you/Ameya might work on? Otherwise we can just put it on the backlog of stuff that I'll take a look at here in the next couple of weeks.

[JatinSanghvi]

@Charles-Gagnon, I have few minor changes done yesterday. I will check tomorrow if something more can be added and create a PR. If we think that there is additional scope for cleanup around inter-thread locking, then possibly Ameya can pick up task for that.