Cache sticky endpoint channels

[schlosna]

Before this PR

Dialogue clients that make heavy use of sticky channels incur a significant construction overhead (e.g. see palantir/conjure-java#2869 ) leading to per-endpoint TypeMarker
anonymous classes, ExceptionDeserializerArgs instances, and Deserializer fields,
causing excessive allocations on high throughput services.

This adds unnecessary overhead for conjure clients that use sticky channels such as ⛰️ clients via e.g. DataServiceAsync#of(com.palantir.dialogue.EndpointChannelFactory, com.palantir.dialogue.ConjureRuntime).

See #2647 which was a basis for this PR.

After this PR

==COMMIT_MSG==

Summary

• Introduce StickyEndpointChannelsFactory interface — replaces the Supplier<Channel> return type from StickyEndpointChannels2.create() and DialogueChannel.stickyChannels() with a typed stickyChannel() method. DialogueChannel now directly implements this interface, and DialogueChannel.stickyChannels() is deprecated in favor of stickyChannel().
• Extract CachingEndpointChannelFactory — encapsulates the Caffeine LoadingCache<Endpoint, EndpointChannel> with delegate::endpoint as the loader into a reusable EndpointChannelFactory implementation. Cache size is configurable via Config.maxEndpointCacheSize() (default 1000), and caching is bypassed when set to <= 0.
• Simplify StickyEndpointChannels2 internals — removes the StickyEndpointChannels2EndpointFactorySupplier and StickyEndpointChannel inner classes; queue override attachment and sticky routing are now inlined in StickyChannel2.endpoint(), reducing indirection.
• Update ReloadingClientFactory — InternalDialogueChannel now extends StickyEndpointChannelsFactory instead of declaring its own stickyChannels() method, and callers use the new stickyChannel() API directly.

Test plan

• Existing StickyEndpointChannels2Test passes (caching behavior is identical, just encapsulated)
• SimulationTest passes and regenerated simulation resources reflect updated sticky channel behavior
• ReloadingClientFactoryTest passes with the new stickyChannel() API

==COMMIT_MSG==

Possible downsides?

This encapsulates a cache of Endpoint -> EndpointChannel so there will be some memory overhead; however, use of sticky channels implies these routes intend to stick around in memory and amortize overhead for benefit of throughput.

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Cache sticky endpoint channels

Check the box to generate changelog(s)

• Generate changelog entry

[changelog-app]

✅ Successfully generated changelog entry!

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

---

📋Changelog Preview

💡 Improvements

• Cache sticky endpoint channels (#2993)