ENH: Add parallel implementation for Distance Measures (eccentricity, diameter, radius, center, periphery)

[ANJAN672]

Description

This PR addresses #82 by adding parallel implementations for several "embarrassingly parallel" distance algorithms. These measures are computationally intensive ($O(V \times (V+E))$), making them ideal candidates for parallelization across node-specific shortest path traversals.

Algorithms added:

• eccentricity (Primary parallel engine)
• diameter
• radius
• center
• periphery

Key Features:

• Optimized Strategy: The implementation parallelizes the shortest path calculations for each node using joblib.
• Performance Policies: Integrated with nxp.should_run_if_large to ensure parallel overhead is only incurred when it provides a meaningful speedup for larger graphs.
• Smart Fallbacks:
  • Automatically falls back to sequential NetworkX if shortest paths (sp) are precomputed or if a single node (v) is queried.
  • Specifically handles directed and undirected graphs according to NetworkX standards.
• Clean Registry: Functions are properly registered in interface.py and exported via nx_parallel.algorithms.
• Documentation: Backend metadata updated so that parallel details appear correctly in the NetworkX documentation.

Testing

• Added comprehensive unit tests in nx_parallel/algorithms/tests/test_distance_measures.py.
• Verified that all 108 tests (including existing suite) pass successfully.
• Correctly handles disconnected graphs and strongly connected components in digraphs (raising NetworkXError as per sequential behavior).

Checklist

• Follows the General guidelines on adding a new algorithm.
• Correct docstring format for backend documentation.
• No n_jobs parameter added to functions (respects global config).
• Code formatted with ruff format.

[Schefflera-Arboricola]

i haven't reviewed the implementation in detail yet but have left a few comments below.

Pls consider taking a look at PR #97 (similar diameter algorithm). And consider cherry-picking relevant commits from that PR and crediting the original author in your commit messages, instead of reimplementing from scratch, to avoid duplication of effort. Thanks!

[Schefflera-Arboricola]

are these tests necessary? we already run nx tests with ParallelGraph obj

[Schefflera-Arboricola]

this seems like a typo

Suggested change

	.DS_Storeuv.lock
	.DS_Store

[Schefflera-Arboricola]

i see usebounds is not being used in the implementation below-- consider using can_run here. Same for the following algorithms..

[ANJAN672]

Thank you very much for your guidance, all done as u said !!

[ANJAN672]

Thank you for pointing out PR #97! I reviewed it and noticed that PR #97 implements the specialized iFub4S algorithm for diameter, which is optimized for real-world undirected unweighted graphs. My implementation takes a different approach - it parallelizes the basic eccentricity computation, which then enables parallel versions of diameter, radius, center, and periphery.

The two approaches could potentially complement each other - iFub4S for fast diameter-only calculations, and my implementation for when users need multiple distance measures. Would you like me to integrate both approaches, or keep them as separate implementations?