Allow for smooth upgrading between underlaying protocol versions

[llucax]

What's needed?

We need to be able to upgrade to newer protobuf versions without breaking all user code.

Proposed solution

In general:

• Always require using conversion functions between the provided Python wrappers and the protobuf messages, even for enums.
• Group conversion functions by protobuf version to ensure only the necessary protobuf files are imported to avoid bloat.
• Be more explicit about for which protobuf version conversion functions are.

In particular:

• Stop using protobuf values as enum values in wrappers
  • Using a protobuf values ties the wrapper to a particular protobuf version
  • It forces to import a particular version of protobuf messages even if we want to use a different version, causing import bloat
  • Allows to accidentally pass values to protobuf functions
• Use simple int values as enum values instead
  • Consider enum values opaque, using the values besides printing them for debugging should be forbidden
  • This allows us to still maintain a 1-1 mapping of values with the latest protobuf version for improved debuggability in most cases (people using the latest version)
• Add a .proto.<version> (for example frequenz.client.common.metrics.proto.v1alpha8) package containing the conversion functions for each supported protobuf version

The new conversion functions should be added in v0.3.x, as well as doing as much deprecation as possible to guide users towards an upgrade to v0.4.0 that is as smooth as possible.

Enum members should keep their current values in v0.3.x, and only be updated to ints in v0.4.0 to ensure v0.3.x stays backwards compatible, but allowing users to migrate to use conversion functions at their own pace. If they do so before v0.4.0, the upgrade to v0.4.0 should not even be a breaking change.

Additional context

This approach gives full flexibility to manage protocol-level breaking changes in a much more graceful way, allowing us to provide backwards-compatible upgrade paths via deprecations.

[llucax]

I submitted 2 pull requests as a proof of concept for this:

• Backwards-compatible changes, just adding the conversion functions, that for now are trivial, and testing the protobuf and Python enum match. Users can already upgrade to use the new conversion functions.

  Add metric from/to protobuf v1alpha8 conversion #140

• Backwards-incompatible change, replacing the Python enum values from the protobuf enum values to plain ints. This should prevent implicit conversions, at least to protobuf. It still permits Metric(protobuf_value), but to avoid that we would need to either use another built-in type for the value (like str), which will make matching the enum values to the latest protobuf version less clear, or having a NewType for the value, but I feel it might be overkill, but we could consider it in the future.

  Forbid implicit Metric to protobuf conversion #142