Derive DisciplineServer from the servicer base class (#70)

[chrislupp]

Closes #70.

DisciplineServer derived from disc.DisciplineService, which despite the name
is the generated experimental client-side API — a set of @staticmethods that
each open a one-shot channel to a target address. The servicer base that
add_DisciplineServiceServicer_to_server is written against is
DisciplineServiceServicer. ExplicitServer and ImplicitServer already mixed
in the correct servicers, so the inconsistency was confined to the base class.

Impact

No shipping code path reached the difference. The registration helper looks
handlers up by name rather than by type, and DisciplineServer overrides all
eight RPCs itself, so the inherited staticmethods were always shadowed. This is
a latent-correctness fix, not a fix for an active bug.

What it protects is an RPC left undefined — realistically one added to the
.proto and regenerated but not yet implemented here. Note that the issue
describes that case incorrectly: it claims an AttributeError at registration
time. Registration actually succeeds, because the static API supplies the
attribute. The failure lands at call time instead, and its shape depends on
whether anything in the process has imported grpc.experimental:

• without it — AttributeError: module 'grpc' has no attribute 'experimental'
• with it — the staticmethod binds gRPC's context argument to its own target
  parameter and fails with TypeError: Argument 'target' has incorrect type (expected bytes, got Mock) while trying to dial the ServicerContext as a
  network address

Either way the handler raises without setting a status, so the client sees
UNKNOWN on a live request. After this change the servicer default sets
UNIMPLEMENTED and reports it properly.

MRO

Both subclasses resolve cleanly:

• ExplicitServer → DisciplineServer → DisciplineServiceServicer → ExplicitServiceServicer → object
• ImplicitServer → DisciplineServer → DisciplineServiceServicer → ImplicitServiceServicer → object

Tests

Two regression tests in tests/test_discipline_server.py: one asserts the base
class directly, the other rebuilds DisciplineServer without its own GetInfo
and checks the inherited method is the servicer's UNIMPLEMENTED default rather
than the static client stub. Both were confirmed to fail against the old base and
pass against the new one, so they catch a revert.

Full suite: 335 passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!