Closes gh-22504

Replace the full category capped at 36 chars with the class name only
and 1 char per package, e.g. org.apache.commons.Foo -> o.a.c.Foo

Includes efficient check for same ClassLoader in ClassUtils.isVisible, efficient MethodMatchers check for IntroductionAwareMethodMatcher, and supertype method resolution in MethodMapTransactionAttributeSource.

Issue: SPR-16723

Issue: SPR-16675
Issue: SPR-16677

Autowiring implicitely Kotlin primary constructors
when there are secondary constructors has side effects
on ConstructorResolver. It seems reasonable to
require explicit @Autowired annotation in such case.

With this commit, implicit autowiring of Kotlin
primary constructors is only performed when there
is a primary constructor defined alone or with
a default constructor (define explicitly or
generated via the kotlin-noarg compiler plugin
or via optional constructor parameters with default
values).

Issue: SPR-16022

This commit improves the component index so that it supports ant-style
package name (i.e. com.example.**.foo).

Issue: SPR-16152

Issue: SPR-10502

This commit adds a "spring-context-indexer" module that can be added to
any project in order to generate an index of candidate components defined
in the project.

`CandidateComponentsIndexer` is a standard annotation processor that
looks for source files with target annotations (typically `@Component`)
and references them in a `META-INF/spring.components` generated file.

Each entry in the index is the fully qualified name of a candidate
component and the comma-separated list of stereotypes that apply to that
candidate. A typical example of a stereotype is `@Component`. If a
project has a `com.example.FooService` annotated with `@Component` the
following `META-INF/spring.components` file is generated at compile time:

```
com.example.FooService=org.springframework.stereotype.Component
```

A new `@Indexed` annotation can be added on any annotation to instructs
the scanner to include a source file that contains that annotation. For
instance, `@Component` is meta-annotated with `@Indexed` now and adding
`@Indexed` to more annotation types will transparently improve the index
with additional information. This also works for interaces or parent
classes: adding `@Indexed` on a `Repository` base interface means that
the indexed can be queried for its implementation by using the fully
qualified name of the `Repository` interface.

The indexer also adds any class or interface that has a type-level
annotation from the `javax` package. This includes obviously JPA
(`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and
servlet annotations (i.e. `@WebFilter`). These are meant to handle
cases where a component needs to identify candidates and use classpath
scanning currently.

If a `package-info.java` file exists, the package is registered using
a "package-info" stereotype.

Such files can later be reused by the `ApplicationContext` to avoid
using component scan. A global `CandidateComponentsIndex` can be easily
loaded from the current classpath using `CandidateComponentsIndexLoader`.

The core framework uses such infrastructure in two areas: to retrieve
the candidate `@Component`s and to build a default `PersistenceUnitInfo`.
Rather than scanning the classpath and using ASM to identify candidates,
the index is used if present.

As long as the include filters refer to an annotation that is directly
annotated with `@Indexed` or an assignable type that is directly
annotated with `@Indexed`, the index can be used since a dedicated entry
wil be present for that type. If any other unsupported include filter is
specified, we fallback on classpath scanning.

In case the index is incomplete or cannot be used, The
`spring.index.ignore` system property can be set to `true` or,
alternatively, in a "spring.properties" at the root of the classpath.

Issue: SPR-11890

Issue: SPR-14585

Issue: SPR-14585

Issue: SPR-11217

This commit also removes support code for outdated options which were only available in older schema versions.

Issue: SPR-13499

Issue: SPR-14429

This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.

Issue: SPR-14431

This commit also removes outdated support classes for Oracle, GlassFish, JBoss.

Issue: SPR-14429

AopUtils.canApply properly matches package-visible methods (aligned with advice matching within proxies)

Also, AbstractAutoProxyCreator considers Pointcut as infrastructure class, analogous to Advice and Advisor.

Issue: SPR-14174

Issue: SPR-13987

Issue: SPR-13987

Issue: SPR-5839

Add a test that explicitely validates that `@ManagedResource` and friends
can be set on an interface.

Issue: SPR-13138

Previously, if a `@Cacheable` method was accessed with the same key by
multiple threads, the underlying method was invoked several times instead
of blocking the threads while the value is computed. This scenario
typically affects users that enable caching to avoid calling a costly
method too often. When said method can be invoked by an arbitrary number
of clients on startup, caching has close to no effect.

This commit adds a new method on `Cache` that implements the read-through
pattern:

```
<T> T get(Object key, Callable<T> valueLoader);
```

If an entry for a given key is not found, the specified `Callable` is
invoked to "load" the value and cache it before returning it to the
caller. Because the entire operation is managed by the underlying cache
provider, it is much more easier to guarantee that the loader (e.g. the
annotated method) will be called only once in case of concurrent access.

A new `sync` attribute to the `@Cacheable` annotation has been addded.
When this flag is enabled, the caching abstraction invokes the new
`Cache` method define above. This new mode bring a set of limitations:

* It can't be combined with other cache operations
* Only one `@Cacheable` operation can be specified
* Only one cache is allowed
* `condition` and `unless` attribute are not supported

The rationale behind those limitations is that the underlying Cache is
taking care of the actual caching operation so we can't really apply
any SpEL or multiple caches handling there.

Issue: SPR-9254

Even though the JSR-107 spec forbids to store null values, our cache
abstraction allows that behaviour with a special handled (and this is
the default behaviour).

While this was working fine with our own set of annotations, the
JSR-107 interceptor counterpart was interpreting the spec sensu strictu.

We now allow for that special case as well.

Issue: SPR-13641

Issue: SPR-7794

Issue: SPR-13461

While working on SPR-12532, an extra IdentityWrapper was added to work
around a backward compatible issue between commons pool 1.x and 2.x. This
issue (POOL-283) has actually been fixed in 2.4 and their IdentityWrapper
is using object equality so our wrapper is in the way.

Looking retrospectively, the code looks all fine without the workaround
and commons pool 2.4 or later so it has been removed.

Previously, a Bean implementing `AutoCloseable` (or `Closeable`) was
always destroyed regardless of its bean definition. In particular, the
documented way of disabling the destruction callback via an empty String
did not work.

AutoCloseable beans are now treated pretty much as any other bean: we
still use the presence of the interface to optimize the check of a
destroy method and we only auto-discover the method name to invoke if
the inferred mode is enabled.

Issue: SPR-13022

This commit also completes 4.2 schema variants in spring-context.

Issue: SPR-5215

Prior to this commit, the GroovyBeanDefinitionReader claimed (via its
Javadoc) that it fully supported XML configuration files in addition to
its Groovy DSL; however, this was unfortunately inaccurate since XML
validation was disabled by default which led to certain features of XML
configuration not working. For example, it was impossible to define a
<qualifier> in an XML config file without specifying the 'type'
attribute (which has a default value defined in the spring-beans XSD).

This commit fixes this issue by ensuring that bean definitions in XML
resources are loaded with a "standard" XmlBeanDefinitionReader that is
created with default settings (i.e., with XML validation enabled). With
regard to backwards compatibility, bean definitions defined using the
Groovy DSL are still loaded with an XmlBeanDefinitionReader that has
XML validation disabled by default which is necessary for proper
parsing of the Groovy DSL.

Issue: SPR-12769

Issue: SPR-12766

Previously, the exception-handler attribute was not taken care of when
task:annotation-driven is used in AspectJ mode. This commit provides the
expected behavior.

Issue: SPR-12619

Add support for annotation-based event listeners. Enabled automatically
when using Java configuration or can be enabled explicitly via the
regular <context:annotation-driven/> XML element. Detect methods of
managed beans annotated with @EventListener, either directly or through
a meta-annotation.

Annotated methods must define the event type they listen to as a single
parameter argument. Events are automatically filtered out according to
the method signature. When additional runtime filtering is required, one
can specify the `condition` attribute of the annotation that defines a
SpEL expression that should match to actually invoke the method for a
particular event. The root context exposes the actual `event`
(`#root.event`) and method arguments (`#root.args`). Individual method
arguments are also exposed via either the `a` or `p` alias (`#a0` refers
to the first method argument). Finally, methods arguments are exposed via
their names if that information can be discovered.

Events can be either an ApplicationEvent or any arbitrary payload. Such
payload is wrapped automatically in a PayloadApplicationEvent and managed
explicitly internally. As a result, users can now publish and listen
for arbitrary objects.

If an annotated method has a return value, an non null result is actually
published as a new event, something like:

@EventListener
public FooEvent handle(BarEvent event) { ... }

Events can be handled in an aynchronous manner by adding `@Async` to the
event method declaration and enabling such infrastructure. Events can
also be ordered by adding an `@order` annotation to the event method.

Issue: SPR-11622