We replaced the component scan in RespositoryRestMvcConfiguration with dedicated bean methods. This allows us to be more explicit in resolving required components, which is required for better support of GraalVM native image.
Original pull request: #382.
Removed Java8PluginRegistry not in use anymore anyway. Same for RepositoryRestConfigurerAdapter. Deprecated legacy ResourceMappingUtils and its client code exposed in RepositoryRestConfiguration as it's also not considered anymore.
Turns out that Spring Boot references DelegatingHandlerMapping from its metrics integration to pick up the HandlerMappings delegated to. Reintroduced the relevant type in deprecated form and also let it implement Iterable<HandlerMapping> so that client code can be moved to generally check for HandlerMappings implementing that and pick up the delegates that way.
Slightly tweaked the configuration model to rather handle the CorsRegistry via RepositoryRestConfigurer.configureRepositoryRestConfiguration(…) rather than RepositoryRestConfiguration itself. That allows moving of Spring WebMVC as a dependency in the core module.
The original methods exposing access to the CorsRegistry are now still available in deprecated form to not break existing clients.
Follow-up ticket: DATAREST-1542.
We now use Spring's path prefix capabilities to apply Spring Data REST's base path to its mappings. This was previously implemented by tweaking the matching conditions.
We now also pick up Spring 5.3's PathPatternParser and apply that to the custom HandlerMapping implementations we register.
Moved DelegatingHandlerMapping into the configuration package to be able to keep it around in package scope.
Deprecated RepositoryRestConfiguration.getBaseUri() as we have only supported paths for quite a while now. Moved all client code to ….getBasePath() instead.
