Protobuf wrappers guideline

• As a general rule, files should be mapped like x/y/z.proto -> x/y/_z.py.

• A python package file should be added to export all symbols in individual files, for example: if there is x/y/_z.py with message/class Z, x/y/_v.py with enum V, and x/y/_w.py with message W, the file x/y/__init__.py should re-export Z, V and W.

• If it is the only file in the x/y/ directory (and thus is the only content of protobuf package x.y), then the file (for example x/y/z.proto) should be converted instead directly into one python module: x/y.py.

• If a symbol in package x.y.pkg starts with pkg, like PkgInfo, then the python symbol should be named without the prefix (Info), unless it is fundamental to the name.

• Wrappers in frequenz-client-common-python and frequenz-client-base-python target API client developers, not end users. In general the wrappers should be suitable for end user consumption, but there might be wrappers that clients should never export because they are just implementation details, like pagination.

• Because of the above, client repos should re-export wrappers in the frequenz-client-common-python and frequenz-client-base-python repos when appropriate, they should never require the user to declare the dependency of frequenz-client-common-python or frequenz-client-base-python manually, or to import stuff from frequenz.client.common or frequenz.client.base directly.

• The functions to convert from/to protobuf to a wrapper should not be part of the wrapper classes, as we don't want to expose the protobuf internals to the users, instead they should be free functions in a separate module, following the pattern <module>_proto.py