feat: add per-node limit on requeues and add safe skip zero-move Leid…

[taisnguyen]

See #35 for a initial discussion. This pull request diverges slightly. The following are the main changes:

1. Upon implementation of the requeue fix, we saw a "cascading effect" within larger graphs, where nodes were repeatedly getting moved and requeued. This significantly increased runtime. As a trade-off, we introduce a per-node limit on the number of requeues possible.
2. Within an outer iteration are multiple inner Leiden iterations. Each inner Leiden iteration successfully moves increasingly less nodes until eventually all following iterations successfully move zero nodes. In the current design, we wait until we hit the maximum inner iterations limit (defaultly set at 20) before we move on to the next outer iteration. In this pull request, we propose the following safe check: if we see that zero successful moves have been made and the following refinement phase made no changes, then we skip to the next outer iteration. Our benchmarks show this saves from 22% - 55% of runtime.

Below is a diagram of various implementations we benchmarked and their runtimes, memory, and achieved total CPM on the ABM14 network (n=14mil, m=581mil). Each implementation is isolated from another (unless specified otherwise with the + symbol).

- BUGGY: This is the current Icebug Leiden-CPM, which suffers from the node-scheduling bug, i.e., nodes may not get relooked at after its neighbor successfully moves, as well as zero-move inner Leiden iterations.
- REQUEUE_FIX: This fixes the node-scheduling bug and adds a parameter which decides a per-node successful-move limit. This limit differs from the per-node requeue limit, since a node may be requeued and not successfully move when processed.
- QUICK: This checks if no moves have been made and that the refinement phase made no changes, and if so skips to the next outer iteration.
- PR_VERSION: This is this pull request's implementation, which combines QUICK and REQUEUE_FIX but using a per-node requeue limit instead of a per-node successful-move limit.
- SERIAL: This is leidenalg's serial Leiden-CPM.

For the default per-node requeue limiit, we choose 24, since our benchmarks show that it does not significantly increase runtime, while improving CPM significantly. Users should be careful not to choose a too-low value, such as 10, since we have seen high variance with runtimes, which may indicate a lower clustering quality.

Next Steps: We still want to confirm whether a per-node requeue limit or a per-node successful-move limit is more suitable, concerning runtime and clustering quality.

[adsharma]

Look good. Merging. Minor comments for future reference:

• We don't have a code format/linter in this repo unlike https://github.com/LadybugDB/ladybug
• Generally avoid trailing whitespace
• std::uint8_t vs uint8_t - think we should be consistent (right now the code base seems to have more of stdint.h variant, not cstdint)

I'll run a one time clang-format after the commit and add a linter in the next few days.