Tests for the PR: Add concurrency cap to identify push handling

[seetadev]

@lla-dane: This is a great improvement — limiting concurrency with a semaphore is a smart and pragmatic way to keep things stable at scale. Thanks for implementing this so cleanly!

As @pacrob mentioned, it’d be great to include a test to confirm the concurrency limit works as expected. Here are a few suggested test scenarios you might consider adding:

Suggested Test Cases for Concurrency Limiting:

1. Max Concurrency Cap Test

   • Connect to, say, 50 mock peers.
   • Use a counter (e.g. with trio.Event or logging timestamps) to assert that no more than 10 identify tasks run concurrently.
   • You could simulate each identify task with a short await trio.sleep() to simulate network delay.

2. Semaphore Enforcement Test

   • Wrap the identify push function and count active tasks using an async-safe counter.
   • Assert that the count never exceeds the semaphore limit (default is 10).

3. Functional Equivalence Test

   • Confirm that identify data is still correctly pushed to all peers despite throttling.
   • Ensure no peer is skipped or missed.

4. Performance Stability Test (Optional)

   • Measure CPU or task count when running with 500+ simulated peers and compare results before and after the semaphore patch (could even just be logged to stdout).
   • Confirm that "Too many open files" or related exceptions no longer appear.

Let me know if you’d like help structuring the test or mocking peers for this setup — happy to assist! Once the test is in place, this should be good to merge.

[seetadev]

@lla-dane : Wish to share suggested Test Titles for Semaphore-Based Concurrency Limiting:

1. test_identify_push_respects_concurrency_limit
   Verifies that no more than the configured number of identify tasks run concurrently.

2. test_all_peers_receive_identify_push_with_semaphore
   Ensures that all peers eventually receive the identify message, even with concurrency limits.

3. test_identify_push_does_not_exceed_file_descriptor_limits (optional/stress test)
   Simulates many peers and confirms that the system remains within OS resource limits (e.g., no "too many open files" errors).

4. test_identify_push_with_semaphore_is_functionally_equivalent
   Confirms that throttling does not affect the correctness of identify data delivery.

5. test_semaphore_limit_is_respected_under_high_peer_load
   Validates semaphore enforcement when pushing identify info to a large number of peers (e.g., 500+).

[lla-dane]

Sure @seetadev , thank you for the clear directives. I will carry out the suggested test plans soon.