Make sklearn.neighbors algorithms treat all samples as neighbors when `n_neighbors is None`/`radius is None`

### Describe the workflow you want to enable

The proposed feature is that algorithms in `sklearn.neighbors`, when created with parameter `n_neighbors is None` or `radius is None`, treat all samples used for fitting (or all samples to which distances are `'precomputed'`) as neighbors of every sample for which prediction is requested.

This makes sense when algorithm parameter `weights` is not `'uniform'` but  `distance` or callable, distributing voting power among fitted samples unevenly. It expands which customized algorithms (that use distance-dependent voting) are available with scikit-learn API.

### Describe your proposed solution

The solution:

1. allow the algorithm parameters `n_neighbors`/`radius` to have the value `None`;
2. allow the public method `KNeighborsMixin.kneighbors` to return ragged arrays instead of 2D arrays (for the case of working on graphs instead of dense matrices);
3. make routines that process indices/distances of neighbors of samples work with ragged arrays;
4. add the special case for the parameter being `None` in routines that find indices of neighbors of a sample.

Examples of relevant code for k-neighbors algorithms:

1. `sklearn.neighbors._base._kneighbors_from_graph`
   Add special case to return a ragged array of indices of all non-zero elements in every row (an array per row, taken directly from `graph.indptr`).

1. `sklearn.neighbors._base.KNeighborsMixin._kneighbors_reduce_func`
   Add special case to produce `neigh_ind` from `numpy.arange(...)` instead of `numpy.argpartition(...)[...]`.

3. `sklearn.neighbors._base.KNeighborsMixin.kneighbors`
   In the end, where the false extra neighbor is removed for every sample, add case for a ragged array.

4. `sklearn.neighbors._base.KNeighborsMixin.kneighbors_graph`
   Add special case to forward results of `.kneighbors(...)` to output.

5. `sklearn.metrics._pairwise_distances_reduction`
   I don't comprehend Cython yet and have no ide what is going on there. Anyway, it's probable that the best case would be to deem the Cython implementation unsuitable for the case discussed (as it is already deemed for other conditions).

### Describe alternatives you've considered, if relevant

The alternative is to build the application in such way that a k-neighbors estimator is instantiated only when the size of dataset is known, setting `n_neighbors` to this size. This possibly causes unwarranted overhead cost for operations that do seek n neighbors, and, as I understand, this is not the conventional way to employ estimators.

### Additional context

When I started investigating the necessary changes, I didn't realize there will be so much code to rewrite because of graphs. I have not found a way to do what I originally needed to do (with dense matrices of precomputed distances) without modifying library's code deeply.

I have also not found this feature proposed earlier. I see why this idea is not so very good, and this issue can tell others.

COMMENT:
Can you explain your motivations behind this? What use case would it enable if you had this feature?

Labels: New Feature