feat: merge zeebe-grpc to pyzeebe

[dimastbk]

Merge zeebe-grpc to pyzeebe
Add mypy-stubs to bundled zeebe-grpc
Bump protobuf to 5.28 (breaking change?)

based on #476
close #475 close #476

cc @felicijus

[dimastbk]

MR on gitlab - one week w/o response.

[felicijus]

Hi, can I help somehow ? Or is this already done?

[github-actions]

Pull Request Test Coverage Report for Build 12516152737

Details

• 123 of 348 (35.34%) changed or added relevant lines in 7 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-14.6%) to 82.413%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pyzeebe/proto/gateway_pb2_grpc.py	104	191	54.45%
pyzeebe/proto/gateway_pb2.py	13	151	8.61%

Totals
Change from base Build 12496073246:	-14.6%
Covered Lines:	1209
Relevant Lines:	1467

---

💛 - Coveralls

[dimastbk]

Hi. I think it's done, need review.

[felicijus]

Will do, in the meantime should the generated files be excluded from coverage ?

[dimastbk]

Yes, fixed

[felicijus]

Looks good on first impression, like the addition with the update.py.

When does this get run, is it manually or during release/pre-commit ?

[dimastbk]

Manually

[felicijus]

Code itself is solid.

But I think we can now avaid using custom type classes like in grpc_internals/types.py

[dimastbk]

But I think we can now avaid using custom type classes like in grpc_internals/types.py

I prefer don't expose transport types to clients.

[felicijus]

Ok, I suppose I know what you mean.
I would like to test how the implementation, would look like when using the generated protobuf Message classes.

Reason for this is the protobuf documentation of Message:

Message provides methods you can use to check, manipulate, read, or write the entire message, including parsing from and serializing to binary strings.

Which would provide everything we need, with the added benefit of not being independent from the generated classes, which could lead to uncatched incompatibilities between the generated classes and the custom type classes.

PS. Will test this in #476

[dimastbk]

which could lead to uncatched incompatibilities between the generated classes and the custom type classes

It's can be caught with mypy and tests (or issues). Clients should not know anything about the transport. And it will be the breaking change, w/o changing Messages.

Any other comment? I would like to merge before NY.

[felicijus]

I think it's fine for now, happy merging. 🎆

[felicijus]

Will this be 4.x.x or 5.x.x ? 🎆

[dimastbk]

4.x.x