Flaky operationIds for controller-methods with same name

[kaibra]

Describe the bug
Given a controller with methods of the same name, the operationIds are automatically build to be unqiue by appending an increasing number (eg "_1") to the method-name. The ids are not being build deterministically. Two runs can lead to different operationIds for a path in the spec.

To Reproduce

@RestController
public class OperationIdController {

    @GetMapping(path = "/test_0")
    public String opIdTest() {
        return "";
    }

    @GetMapping(path = "/test_1")
    public String opIdTest(@RequestParam String param) {
        return "";
    }

    @GetMapping(path = "/test_2") 
    public String opIdTest(@RequestParam Integer param) {
        return "";
    }

    @GetMapping(path = "/test_3")
    public String opIdTest(@RequestParam Boolean param) {
        return "";
    }

}

If you have a look at the OpenAPI calculated for this Controller, operationIds are flaky and can change for the given paths.

Expected behavior
Even though it may not make sense to have such a controller set up, the behaviour should be deterministic.
A given Controller should always lead to the same OpenAPI being calculated.

Additional context
There is already a sorting in place here: https://github.com/springdoc/springdoc-openapi/blob/master/springdoc-openapi-common/src/main/java/org/springdoc/api/AbstractOpenApiResource.java#L413 before calculatePath is called.
But not here: https://github.com/springdoc/springdoc-openapi/blob/master/springdoc-openapi-webmvc-core/src/main/java/org/springdoc/webmvc/api/OpenApiResource.java#L244
And here: https://github.com/springdoc/springdoc-openapi/blob/master/springdoc-openapi-webflux-core/src/main/java/org/springdoc/webflux/api/OpenApiResource.java#L193

The EntrySet/Map from RequestMappingHandlerMapping does not seem to have a deterministic order.