[Main] Fix Azure topic settlement flow for long-running messages

[sujata-m]

PR Summary

This PR fixes a locking/settlement issue in AzureTopic.subscribe by moving message settlement back onto the receiver-owned loop instead of settling from worker callback threads. It also tracks pending tasks and in-flight slots more explicitly so concurrency limits and max_receivable_messages remain accurate while messages are still processing.

Additional changes include lock-renew failure logging for better diagnostics on long-running jobs, new unit coverage for task settlement behavior, adding requirements.txt to the package manifest, and bumping the package version to 0.0.25.

Why This Fix Was Added

The previous flow settled messages from worker-thread callbacks while the receiver loop continued managing message intake. For long-running jobs, that creates a risk that receive, lock renewal, and complete/abandon operations fall out of sync, which can surface as lock-related failures or unreliable settlement behavior. The internal in-flight slot count also was not managed in a way that consistently reflected active work, so concurrency limits and bounded receives could become inaccurate under load. We added this fix to keep settlement in the receiver flow, make slot accounting deterministic, and improve diagnosis when lock renewal fails.

Impact

• Improves reliability of message completion and abandon handling for long-running Azure Service Bus consumers.
• Keeps in-flight concurrency tracking accurate so the subscriber does not over-receive while work is still running.
• Preserves max_receivable_messages behavior more predictably during active processing.
• Adds visibility into lock-renew failures through logging, which makes production issues easier to diagnose.
• Reduces the chance of message-processing instability caused by receiver/worker thread coordination.

Testing: unittest passed