Honor BeanDefinition order attribute for DispatcherServlet strategies

[daguimu]

Problem

DispatcherServlet detects four kinds of strategy beans (HandlerMapping, HandlerAdapter, HandlerExceptionResolver, ViewResolver) by type and keeps each list sorted. The sort calls AnnotationAwareOrderComparator.sort(list) directly on the matched bean instances, which only consults @Order on the bean class and the Ordered interface.

Setting the order programmatically — via BeanRegistrar.Spec#order(int), the order parameter on GenericApplicationContext#registerBean(...), or AbstractBeanDefinition#ORDER_ATTRIBUTE directly on a bean definition — has no effect on these strategy lists, even though the same attribute is honored for sorted dependency injection through DefaultListableBeanFactory.FactoryAwareOrderSourceProvider.

Root cause

AnnotationAwareOrderComparator.sort(List) runs without an OrderSourceProvider. With no source provider, the comparator never reaches the bean definition and cannot read ORDER_ATTRIBUTE.

Fix

Add a private helper sortStrategyBeans that sorts the matched list using AnnotationAwareOrderComparator.INSTANCE.withSourceProvider(...). The BeanDefinitionOrderSourceProvider mirrors FactoryAwareOrderSourceProvider exactly:

• Looks up the merged BeanDefinition via ConfigurableApplicationContext.getBeanFactory().getMergedBeanDefinition(...) (which already walks the parent BeanFactory chain).
• Adds the ORDER_ATTRIBUTE value as an Ordered source when present and Integer.
• Adds the factory method as a source for RootBeanDefinition instances (so @Order on a @Bean factory method works).
• Adds the declared target type as a source when distinct from the bean's runtime class.
• Throws IllegalStateException for a non-Integer ORDER_ATTRIBUTE, matching the bean factory's fail-fast behavior.

The helper is applied at all four strategy-detection sites. Beans without ORDER_ATTRIBUTE see no behavior change — the comparator still falls back to @Order / Ordered.

Tests Added

Change Point	Test
sortStrategyBeans honors ORDER_ATTRIBUTE	detectsHandlerMappingsOrderedByBeanDefinitionOrderAttribute
ORDER_ATTRIBUTE overrides class-level @Order	beanDefinitionOrderAttributeOverridesAnnotationOrderForHandlerMappings
ORDER_ATTRIBUTE resolved across parent contexts	handlerMappingOrderFromBeanDefinitionInheritsAcrossParentContext
Non-Integer ORDER_ATTRIBUTE is rejected	nonIntegerOrderAttributeIsRejected

The tests exercise the change through getHandlerMappings() but cover the shared helper used by all four strategies. The full :spring-webmvc:test suite passes.

Impact

• Scope: spring-webmvc only; private API, no public surface added.
• Behavior change is strictly additive for the common case.
• Fail-fast path is only reachable when user code sets ORDER_ATTRIBUTE to a non-Integer directly; public APIs only accept int/Integer.
• Default-strategy fallback (DispatcherServlet.properties) is unaffected.
• WebFlux's DispatcherHandler and OncePerRequestFilter ordering are out of scope.

Closes gh-36637

[rstoyanchev]

Note that we've had to re-write commits in main and 7.0.x over the past 2 days after erroneous merge that this PR was based on. The PR needs to be handled with care focusing on just the one commit 7a05a9e and ignoring the other 4.