split count public getter, events distribution feature

[feyishola]

Summary of Implementation

1. Added Three Public Getter Functions to [contract.rs]
   split_count(e: Env) -> u32 (line 269-272): Returns the total number of splits created
   recurring_count(e: Env) -> u32 (line 299-302): Returns the total number of recurring payments created
   dispute_count(e: Env) -> u32 (line 241-244): Returns the total number of disputes created
   Each function follows the same pattern as the existing escrow_count function:
   Calls bump_instance to extend TTL
   Reads the corresponding counter from storage using read_counter
2. Added Comprehensive Tests for each counter:
   In [splitter_test.rs]
   test_split_count_starts_at_zero: Verifies counter starts at 0
   test_split_count_increments_on_create: Verifies counter increments correctly (tests 3 splits with IDs 1, 2, 3)
   In [recurring_test.rs
   test_recurring_count_starts_at_zero: Verifies counter starts at 0
   test_recurring_count_increments_on_setup: Verifies counter increments correctly (tests 3 recurring payments with IDs 1, 2, 3)
   In [dispute_test.rs]
   test_dispute_count_starts_at_zero: Verifies counter starts at 0
   test_dispute_count_increments_on_open: Verifies counter increments correctly (tests 3 disputes with IDs 1, 2, 3)
3. Purpose:
   These public getters expose the counter keys that already existed in DataKey but weren't accessible to indexers. Indexers can now use these functions to know when to stop paginating through splits, recurring payments, and disputes.All changes maintain consistency with the existing codebase patterns and the existing escrow_count implementation.Summary of Implementation
4. Added Three Public Getter Functions to [contract.rs]
   split_count(e: Env) -> u32 (line 269-272): Returns the total number of splits created
   recurring_count(e: Env) -> u32 (line 299-302): Returns the total number of recurring payments created
   dispute_count(e: Env) -> u32 (line 241-244): Returns the total number of disputes created
   Each function follows the same pattern as the existing escrow_count function:
   Calls bump_instance to extend TTL
   Reads the corresponding counter from storage using read_counter
5. Added Comprehensive Tests for each counter:
   In [splitter_test.rs]
   test_split_count_starts_at_zero: Verifies counter starts at 0
   test_split_count_increments_on_create: Verifies counter increments correctly (tests 3 splits with IDs 1, 2, 3)
   In [recurring_test.rs]
   test_recurring_count_starts_at_zero: Verifies counter starts at 0
   test_recurring_count_increments_on_setup: Verifies counter increments correctly (tests 3 recurring payments with IDs 1, 2, 3)
   In [dispute_test.rs]
   test_dispute_count_starts_at_zero: Verifies counter starts at 0
   test_dispute_count_increments_on_open: Verifies counter increments correctly (tests 3 disputes with IDs 1, 2, 3)
6. Purpose:
   These public getters expose the counter keys that already existed in DataKey but weren't accessible to indexers. Indexers can now use these functions to know when to stop paginating through splits, recurring payments, and disputes.All changes maintain consistency with the existing codebase patterns and the existing escrow_count implementation.

closes #182
closes #183
closes #184
closes #185

[drips-wave]

@feyishola Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits