Resizable semaphore

[rahulksnv]

This is a draft PR based off Nazar's #1017. Specifically this discussion thread: #1017 (comment)

Main change:

1. Implements a semaphore style construct(ResizableSemaphore) that allows both expanding and shrinking of the max permits
2. This uses a constant space/time
3. When the max permits are shrinked: new permit requests would block until outstanding permits are freed and the usage falls below the new lower capacity
4. Unit tests for ResizableSemaphore

End to end testing: TODO

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

Generally I like the API, it is much nicer to use and doesn't require timer, which is even better!

I have some major comments as well as a bunch of nits about our contributing practices and idiomatic Rust more broadly.

---

We don't need to see every single step as you were iterating on the implementation in Git history, squash things before creating PR and look through it to see if unnecessary empty lines or other small nuances were accidentally committed, see CONTRIBUTING.md, which talks about that and much more.
Commits like Clean up should certainly be squashed with original commit it cleans up before pushing, also the whole thing needs to be rebased so that there is no avoidable merge commit in the middle of the history right away.
Please group data structures and corresponding impls together instead of interleaving various definitions with various impls.
Ideally, though not always possible/convenient, data structures should be defined before they are used.

Also latest test run failed and rebase will be necessary due to changes in the branch this targets.

UPD: "Code contributor checklist:" is there to be followed and checked before submitting a PR!

[rahulksnv]

Generally I like the API, it is much nicer to use and doesn't require timer, which is even better!

I have some major comments as well as a bunch of nits about our contributing practices and idiomatic Rust more broadly.

We don't need to see every single step as you were iterating on the implementation in Git history, squash things before creating PR and look through it to see if unnecessary empty lines or other small nuances were accidentally committed, see CONTRIBUTING.md, which talks about that and much more. Commits like Clean up should certainly be squashed with original commit it cleans up before pushing, also the whole thing needs to be rebased so that there is no avoidable merge commit in the middle of the history right away. Please group data structures and corresponding impls together instead of interleaving various definitions with various impls. Ideally, though not always possible/convenient, data structures should be defined before they are used.

Also latest test run failed and rebase will be necessary due to changes in the branch this targets.

UPD: "Code contributor checklist:" is there to be followed and checked before submitting a PR!

Thanks for the feedback. I will address the comments and update you

[rahulksnv]

Generally I like the API, it is much nicer to use and doesn't require timer, which is even better!
I have some major comments as well as a bunch of nits about our contributing practices and idiomatic Rust more broadly.
We don't need to see every single step as you were iterating on the implementation in Git history, squash things before creating PR and look through it to see if unnecessary empty lines or other small nuances were accidentally committed, see CONTRIBUTING.md, which talks about that and much more. Commits like Clean up should certainly be squashed with original commit it cleans up before pushing, also the whole thing needs to be rebased so that there is no avoidable merge commit in the middle of the history right away. Please group data structures and corresponding impls together instead of interleaving various definitions with various impls. Ideally, though not always possible/convenient, data structures should be defined before they are used.
Also latest test run failed and rebase will be necessary due to changes in the branch this targets.
UPD: "Code contributor checklist:" is there to be followed and checked before submitting a PR!

Thanks for the feedback. I will address the comments and update you

I will squash the commits next

[nazar-pc]

Looks good, just a few minor things

[nazar-pc]

One nit, looks great otherwise!

[nazar-pc]

Will merge once CI passes, thanks!

[nazar-pc]

Hm... I was actually waiting for CI to pass before merging