Deduplicate TypeMarker, ExceptionDeserializerArgs, and Deserializer fields in generated dialogue interfaces

[schlosna]

Before this PR

Generated dialogue service interfaces previously created per-endpoint TypeMarker
anonymous classes, ExceptionDeserializerArgs instances, and Deserializer fields,
causing excessive allocations when multiple endpoints share the same return type.

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).

After this PR

==COMMIT_MSG==
This change modifies DefaultStaticFactoryMethodGenerator to:

1. Generate one private static final TypeMarker<T> per distinct return type
   instead of new TypeMarker<T>() {} inline per endpoint.
2. Generate one private static final ExceptionDeserializerArgs<T> per distinct
   return type (error-respecting path), instead of calling
   createExceptionDeserializerArgs per endpoint.
3. Generate one shared Deserializer<T> instance field per distinct return type,
   referenced by all endpoints with the same return type.

For example EteServiceBlocking (36 endpoints, 22 distinct return types) this reduces
anonymous TypeMarker classes, createExceptionDeserializerArgs calls, and
Deserializer allocations from 36 each to 22 each.

==COMMIT_MSG==

Possible downsides?

[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

This change modifies DefaultStaticFactoryMethodGenerator to:

1. Generate one private static final TypeMarker<T> per distinct return type
   instead of new TypeMarker<T>() {} inline per endpoint.
2. Generate one private static final ExceptionDeserializerArgs<T> per distinct
   return type (error-respecting path), instead of calling
   createExceptionDeserializerArgs per endpoint.
3. Generate one shared Deserializer<T> instance field per distinct return type,
   referenced by all endpoints with the same return type.

For EteServiceBlocking (36 endpoints, 22 distinct return types) this reduces
anonymous TypeMarker classes, createExceptionDeserializerArgs calls, and
Deserializer allocations from 36 each to 22 each.

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

• This change modifies DefaultStaticFactoryMethodGenerator to:

  1. Generate one private static final TypeMarker<T> per distinct return type
     instead of new TypeMarker<T>() {} inline per endpoint.
  2. Generate one private static final ExceptionDeserializerArgs<T> per distinct
     return type (error-respecting path), instead of calling
     createExceptionDeserializerArgs per endpoint.
  3. Generate one shared Deserializer<T> instance field per distinct return type,
     referenced by all endpoints with the same return type.

  For EteServiceBlocking (36 endpoints, 22 distinct return types) this reduces
  anonymous TypeMarker classes, createExceptionDeserializerArgs calls, and
  Deserializer allocations from 36 each to 22 each. (#2869)

[pkoenig10]

I probably would prefer if these weren't static. It means that simply loading these classes will requiring initializing and retaining these classes, even if the client is no longer used.

[mpritham]

Discussed internally that this proposed Dialogue change is probably the more useful change to mitigate the overhead from using sticky clients. Hopefully that change will take the construction of these clients out of a hot path.

I think this is a good idea though. I think the hashes added to the variable names when there are name collisions hurts the readability: I wonder if there's another way to deconflict here.

[schlosna]

Discussed internally that this proposed Dialogue change is probably the more useful change to mitigate the overhead from using sticky clients. Hopefully that change will take the construction of these clients out of a hot path.

Fixed up merge conflicts and finished out implementation of #2647 in palantir/dialogue#2955 on top of that branch