[BUG] `roc_auc_score` is wrong (edge case)

### Describe the bug

Hi,

It seems that on the edge case when there are equal scores, [`roc_auc_score`](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.roc_auc_score.html#roc-auc-score) actually makes a wrong comuptation:
```pycon
>>> roc_auc_score([1, 0, 0, 1], [2, 5, 10, 10])
0.375
>>> # Expected 0.25 or 0.5, see below.
```
On would expect either `0.5` or `0.25` depending on whether or not the area is computed by interpolating to the convex hull (which makes sense with probabilistic mixtures for the ROC curve) or not.

I tried illustrating this example below (keep in mind that this behaviour is *speculated* by myself, I didn't go through any of `sklearn` code).

![roc_auc_bug](https://github.com/scikit-learn/scikit-learn/assets/114467748/4a902ca2-fc23-4341-b8b9-6234a9f40fd8)

Any feedback is welcome.
Cheers!

### Steps/Code to Reproduce

```pycon
from sklearn.metrics import roc_auc_score
roc_auc_score([1, 0, 0, 1], [2, 5, 10, 10])
```

### Expected Results

`0.25` or `0.5`

### Actual Results

`0.375`

### Versions

```shell
1.5.0
```

COMMENT:
> The plot in wikipedia https://en.wikipedia.org/wiki/Receiver_operating_characteristic has linear slope sections and is non-convex so it's probably using the same naive linear interpolation as scikit-learn.

Yes probably. It remains not discussed anywhere though.

> And I explained before why I don't think `previous` interpolation is a valid choice (for the case of the constant predictor).

No problem, I accept your opinion. I personally disagree and am not convinced by the constant predictor example and the "chance level" argument. Indeed, I think there are two cases to consider as an operator given a `max_fpr`:
1. **You want to use one simple threshold:** Then you refer to the **step-function** (from `previous` interpolation) and can predict what `tpr` to expect;
2. **You want to maximize your tpr using your classifier:** Then you refer to the `convex hull` ROC function and deduce which stochastic procedure to use in order to expect the best `tpr` possible.

In neither cases the `linear` interpolation plays a significant role. And if you can only use one threshold, there is no reason for your auc to be greater than `0.5` (imagine threshold a perfectly wrong classifier).

> ROCCH seems to be getting traction on the other hand but it's getting traction under that specific name.

It seems like it indeed.

> > and we may consider it unimportant, I would understand it.
> 
> The difference between `previous` and `linear` is probably only visible when the number of tied predictions is very large compared to the dataset size.

In most cases I agree, yes!

> The ROCCH alternative on the other hand seems to have profound implications that are probably worth exploring, for instance:
> 
>     * Technical Note: PAV and the ROC Convex Hull
>       http://www.niculescu-mizil.org/papers/PAV-ROCCH.pdf
> 
>     * Classifier Calibration with ROC-Regularized Isotonic Regression
>       https://proceedings.mlr.press/v238/berta24a.html
> 
> 
> Note that I have not yet carefully read this papers.

Thanks for the refs!

-------------

In conclusion, I thank you for your interest and anwsers. I accept your point of view and will close the issue as requested, while summarizing one last time my recommendations in case of further discussion: 
- Fix current implementation to `previous` interpolation;
- Add a keyword argument `convex_hull: bool = False` _(Note: enabling it to `True` ensures `auc >= 0.5`)_.

Labels: Bug