RFE results are inconsistent between machines with ties in feature importances at threshold

### Describe the bug

RFE uses np.argsort on the feature_importances from the estimator, this is not repeatable across machines. This only matters when there are ties in the feature importances that overlap with the threshold. For example if the importances are [0, 2, 0, 1] and it needs to eliminate 1 feature, it may not choose the same feature to eliminate on all machines.

### Steps/Code to Reproduce

It is difficult to write code that will show this as it requires multiple machines to test; however, the following test could be added to the _rfe unit tests to check if the sort is stable, though the sort could be consistent but not stable, so this isn't enough to prove an issue.
```
def test_rfe_ties_around_threshold():
    X, y = make_classification(n_features=47, random_state=0)
    clf = MockClassifier() # mock classifier returns constant feature_importances
    rfe = RFE(estimator=clf, n_features_to_select=4, step=2)
    rfe.fit(X, y)

    assert_array_equal(rfe.support_ ,np.array([*[False]*43, *[True]*4]))
```

### Expected Results

Expected to get the same results on all machines, being stable is not necessary though it is an easy way to enforce testable consistency.

### Actual Results

Current sort does not result in a stable sort and fails the previously provided unit test.

### Versions

```shell
main branch
```


This issue is most likely to occur with zero importance features, especially at the initial steps of RFE.

COMMENT:
> Maybe this would be suitable?
> 
> ```python
> np.random.rand(n_random) * np.finfo(float_dtype).eps
> ```

Sorry for the delay on this, started work on this again today, but ran into this issue:


>>> importances = (random_state.rand(40) * np.finfo(np.float64).eps)
>>> len(importances)
40
>>> len(np.unique(importances))
40
>>> len(np.unique(1.0 + importances))
2
>>> (1.0 + importances).dtype
dtype('float64')
>>>

Eps seems to be reasonable scale, at least for the small number of features I selected to make unique values. But as soon as the scale of the initial feature importances move from all tied at 0 to all tied at 1.0 this breaks down as there are only 2 unique values selected, since floats are less dense here.

To be fair, the place I personally saw tie issues was at 0...

I can look further into this, and maybe do something more dynamic to the feature importance scale, such as using https://numpy.org/doc/stable/reference/generated/numpy.nextafter.html.

I think this may not be a rabbit hole worth going down? 

Another option, I believe I previously mentioned would be using `np.lexsort`. In this case we could set the last argument to the actual feature importances, and the first argument to a shuffled sequential integer index. This would guarantee no ties and would guarantee reproducible results dependent on the random seed with ties. However, another thing it does that could be seen as good or bad is that it only shuffles ties, it doesn't affect very close feature importances.

Additionally, as @adrinjalali  mentioned with my previous stable sort implementation, this would add a speed cost in some cases.

Labels: Bug