Unused repository plugins consume a lot of metaspace

[original-brownbear]

From looking into ES's metaspace usage the other day ...

Currently, just firing up a default Elasticsearch node that has no repositories configured, one can see that both the Azure and the S3 repositories use up a lot of metaspace even when unsued.
It's ~4.6M for the S3 plugin and ~6.3M for the Azure plugin. This might be a relevant amount of memory for small deployments, e.g. for a 512M heap deployment, an extra wasted 10M of off-heap memory isn't great.

In both cases the main contributor to these numbers is the Jackson dependency, for the Azure dependency redundant loading the Netty which we have on the classpath from the transport already (but in a separate loader) also adds 2M or so.

I wonder if we could introduce some sort of lazy loading here that would allow us to save those 11MB+ of off-heap memory here. Alternatively, maybe we could share the Netty (same version for Azure and the transport) and Jackson (us and S3 share the version here) classes with those already loaded in the transport/core?

relates #81652

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

Sharing with core isn't really possible. We decoupled these intentionally: dependency versions used by plugins should match those dependencies intended versions, not what we happen to use. Having those versions tightly coupled in the past caused headaches for upgrading (we couldn't upgrade jackson for a long time because of azure). Additionally, since we now have hidden jackson inside the x-content jar, there's no easy way to do this (a dependency of server).

We have discussed in the past (though I could not find an issue for it) building some caching of plugin dependency jars automatically. It's still possible, but we would need to be careful it's based on jar hash and not just the jar filenames.