Investigate incompatible signatures of `scipy.linalg.cython_blas.dasum`

### Describe your issue.

In MNE-Python we run a pip-pre job with thhe latest `scipy-wheels-nightly` builds for NumPy/SciPy/sklearn. The latest `1.11.0.dev0+1956.7c74503` SciPy + `1.3.dev0` sklearn pip-pre wheel combination appears to be buggy:

- https://github.com/mne-tools/mne-python/actions/runs/4816481433/jobs/8576144713?pr=11640

It worked with 1.11.0.dev0+1926.070b2a8 in SciPy:

- https://github.com/mne-tools/mne-python/actions/runs/4805236318/jobs/8551461993

Probably because SciPy changed their signature to `int const *` in https://github.com/scipy/scipy/pull/18247.

Some form of this should allow you to reproduce the issue I think:
```
pip install --pre --extra-index-url "https://pypi.anaconda.org/scipy-wheels-nightly/simple" numpy scipy sklearn
```

This is the error message we see in CIs:

```shell
________ ERROR at setup of test_make_forward_solution_kit[testing_data] ________
mne/forward/tests/test_make_forward.py:381: in small_surf_src
    src = setup_source_space('sample', 'oct2', subjects_dir=subjects_dir,
<decorator-gen-115>:12: in setup_source_space
    ???
mne/source_space.py:1439: in setup_source_space
    s = _create_surf_spacing(surf, hemi, subject, stype, ico_surf,
mne/surface.py:1066: in _create_surf_spacing
    mmap = _compute_nearest(from_surf['rr'], ico_surf['rr'])
mne/surface.py:503: in _compute_nearest
    tree = _DistanceQuery(xhs, method=method)
mne/surface.py:525: in __init__
    from sklearn.neighbors import BallTree
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/neighbors/__init__.py:8: in <module>
    from ._distance_metric import DistanceMetric
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/neighbors/_distance_metric.py:4: in <module>
    from ..metrics import DistanceMetric as _DistanceMetric
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/__init__.py:42: in <module>
    from . import cluster
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/cluster/__init__.py:22: in <module>
    from ._unsupervised import silhouette_samples
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/cluster/_unsupervised.py:23: in <module>
    from ..pairwise import pairwise_distances_chunked
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/pairwise.py:40: in <module>
    from ._pairwise_distances_reduction import ArgKmin
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/_pairwise_distances_reduction/__init__.py:89: in <module>
    from ._dispatcher import (
/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py:11: in <module>
    from ._base import _sqeuclidean_row_norms32, _sqeuclidean_row_norms64
sklearn/metrics/_pairwise_distances_reduction/_base.pyx:1: in init sklearn.metrics._pairwise_distances_reduction._base
    ???
sklearn/utils/_cython_blas.pyx:1: in init sklearn.utils._cython_blas
    ???
E   TypeError: C function scipy.linalg.cython_blas.dasum has wrong signature (expected __pyx_t_5scipy_6linalg_11cython_blas_d (int *, __pyx_t_5scipy_6linalg_11cython_blas_d *, int *), got __pyx_t_5scipy_6linalg_11cython_blas_d (int const *, __pyx_t_5scipy_6linalg_11cython_blas_d const *, int const *))
```

```shell
Platform                Linux-5.15.0-1035-azure-x86_64-with-glibc2.35
Python                  3.11.3 (main, Apr  6 2023, 07:55:46) [GCC 11.3.0]
Executable              /opt/hostedtoolcache/Python/3.11.3/x64/bin/python
├☑ numpy                1.25.0.dev0+1207.gafa98ddef (OpenBLAS 0.3.21 with 1 thread)
├☑ scipy                1.11.0.dev0+1926.070b2a8
├☑ sklearn              1.3.dev0
```
Assuming the SciPy change was good/reasonable, it seems like sklearn should adapt to/permit this new signature type. But I might be wrong... 

I've opened https://github.com/scipy/scipy/issues/18377 at the SciPy end in case you want to argue with the SciPy folks that they did something wrong here

COMMENT:
Actually, even if we can fix up scikit-learn so that future releases of scikit-learn can handle both the old and new signature in scipy, for versions of scikit-learn that were already released people will get failures when these scipy changes are released.

Labels: cython