Check node existence before making reverse link in HNSW graph indexing

[Pulkitg64]

Description

Fixes #15467.

This PR implements a brute-force check to prevent duplicate reverse links during HNSW graph indexing. Before creating a reverse link, we iterate through all neighbors of the neighbor node to verify if the current node already exists in its neighbor list. If found, we skip creating the redundant reverse link, preventing duplicate edges in the graph.

[Pulkitg64]

Ran some benchmark to compare performance. For the benchmark I ran two tests,

1st Benchmark Run: Indexed 100k docs with no deletes followed by force-merge. We are seeing around 2-3% drop in indexing rate and no regression in recall

MaxConn	Recall	Indexing Time (s)	Indexing Rate (docs/s)	Force Merge Time (s)	Experiment
8	72.00%	11.54	8667.76	15.3	Baseline
8	72.30%	11.92	8388.56	15.11	Candidate
16	83.20%	14.23	7028.89	24.41	Baseline
16	82.70%	14.53	6882.79	23.51	Candidate
32	89.30%	14.78	6767.73	38.41	Baseline
32	89.20%	15.18	6588.05	38.19	Candidate
64	91.20%	14.73	6788.87	50.41	Baseline
64	91.20%	14.85	6735.37	49.58	Candidate

2nd Benchmark Run: Indexed 100k docs followed by force merge. Then deleted 40% random docs again followed by force merge. Results are same as 1st run i.e around 2-3% drop in indexing rate without regression in recall

MaxConn	Recall	Indexing Time (s)	Indexing Rate (docs/s)	Force Merge Time (s)	Experiment
8	81.50%	11.41	8761.17	43.89	Baseline
8	81.30%	11.4	8772.7	43.65	Candidate
16	90.60%	14.59	6854.95	63.94	Baseline
16	90.60%	14.28	7001.33	65.11	Candidate
32	93.40%	14.69	6808.28	83.33	Baseline
32	93.40%	14.77	6770.48	81.9	Candidate
64	93.90%	14.47	6913.24	89.69	Baseline
64	93.90%	14.54	6879	90.37	Candidate

[msokolov]

Is it possible to make this conditional on whether we're being called by the link repair process? We could add a parameter controlling whether the check is done

[Pulkitg64]

Yes, definitely. Let me do this and raise new revision.