Simplify Server registration

[antonkomarev]

Overview

Simplify registration of server, because PATH_PREFIX constant declares:

Should be used with caution, it only matches routes with the default "/twirp" prefix and default CamelCase service and method names. Use EmployeeServiceServer::getPathPrefix instead.

What this PR does / why we need it

Instead of this:

$this->router->registerHandler(
    EmployeeServiceServer::PATH_PREFIX,
    new EmployeeServiceServer(svc: $this->employeeService),
);

Or this:

$employeeServiceServer = new EmployeeServiceServer(
    svc: $this->employeeService,
);

$this->router->registerHandler(
    $employeeServiceServer->getPathPrefix(),
    $employeeServiceServer,
);

We can do:

$this->router->registerServer(
    new EmployeeServiceServer(
        svc: $this->employeeService,
    )
);

Special notes for your reviewer

New ServerInterface may have new method getMethodPath described here:

• Add method constants to php Server class #206

Does this PR introduce a user-facing change?

New ability to register server without manually define server path.

[antonkomarev]

@sagikazarmark marked as Draft because no tests included and documentation should be updated too. If this proposal is applicable, will invest more time for it.

[antonkomarev]

Swapped it to the new interface, because it is extending RequestHandlerInterface

[sagikazarmark]

Thanks @antonkomarev !

I think this makes sense, although in the past I avoided adding additional dependency on the shared library on purpose, mostly to avoid incompatibility between the generated code and the shared library.

Let me sleep on it before accepting.

[sagikazarmark]

Looks like I described that exact same solution in #89 though, but never got to implementing it...probably because it meant adding an interface to the runtime library.

[antonkomarev]

@sagikazarmark so, you didn't changed your mind from then? )

I think it's redundant to define prefix manually if we already have it in a service object.

[sagikazarmark]

I haven't really given it much thought. I can see how the current UX is not ideal. I'm leaning towards accepting this, I just want to give it some thought to see if we can find an alternate solution.

[antonkomarev]

@sagikazarmark what's wrong with the external interface? Code is generated and doesn't mean to be committed to the application repository. Maybe only in tests.