Unexpected discrepencies between FooService and FooServiceBlocking when introducing new API versions

[Alexis-D]

What happened?

If we start/release a FooService defined as such:

services:
  FooService:
    name: Foo Service
    package: com.palantir.foo
    base-path: /foo
    default-auth: header
    endpoints:
      foo:
        http: GET /foo
        args:
          arg:
            type: string
            param-type: query
        returns: Foo

And then update it to look like this (introducing a new optional query param newArg):

services:
  FooService:
    name: Foo Service
    package: com.palantir.foo
    base-path: /foo
    default-auth: header
    endpoints:
      foo:
        http: GET /foo
        args:
          arg:
            type: string
            param-type: query
          newArg:
            type: optional<string>
            param-type: query
        returns: Foo

Then FooService will generated with a method like this:

@Deprecated
default Foo foo(AuthHeader authHeader, String arg) {
    return foo(authHeader, arg, Optional.empty());
}

Which means that clients using FooService can upgrade their dependency without incurring any dev breaks. FooServiceBlocking however doesn't generate those methods, which makes releasing wire-safe API changes trigger dev breaks for FooServiceBlocking users.

What did you want to happen?

FooServiceBlocking should generate deprecated methods in order to avoid dev breaks. There's a similar argument to be made with FooServiceAsync.

[carterkozak]

Adding context:

We originally chose not to implement the backcompat methods because our goal was to use local codegen for dialogue. We later decided not to use local codegen because it became more complicated for some scenarios involving interactions with supporting libraries and external imports so it was never fully rolled out.
Revisiting our assumptions I think it's reasonable to generate the backcompat method stubs.