fix(996): Do not release database lock early for subscriptions

[joshua-spacetime]

Fixes #996.

Description of Changes

Please describe your change, mention any related tickets, and so on here.

API and ABI breaking changes

If this is an API or ABI breaking change, please apply the
corresponding GitHub label.

Expected complexity level and risk

How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.

This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.

If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.

Testing

Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!

• Write a test you've completed here.
• Write a test you want a reviewer to do here, so they can check it off when they're satisfied.

[Shubham8287]

I feel we do not need to drop(tx) early for any correctness issue, we can do it being more conserative.

dropping subscription lock should be enough as that will also not let the reducers to commit (reducer need subscription read lock to commit), so their eval_incr will also not start.

if we not drop(tx) early, reducer execution will not happen parallel to eval, though right now we are letting execution to happen but not commit (which is also fine).

At the end, it depends whether we want to be more conservative or look for bit more perfomance.

[joshua-spacetime]

We discussed async: Holding the tx for the lifetime of the call does keep a reducer from executing until we push onto the send queue, but that shouldn't have a noticeable impact on throughput, plus it makes testing easier. So I think we're both in favor of this from a correctness standpoint.