Unexpected discrepencies between FooService and FooServiceBlocking when introducing new API versions

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.

Start at the Java generator entry points for FooServiceBlocking and compare them with the existing FooService compatibility-method generation; also inspect the analogous FooServiceAsync path mentioned in the issue. Done means blocking and async services generate deprecated overloads when a new optional query parameter is introduced, preserving source compatibility for existing clients.