Make Message Object Instantiable By Users

[ojasvajain]

Overview

1. Fixes issue feature request: make Message type user-instantiable #1535 by allowing Message objects to be instantiable by users.
2. Modify type hints of topic(), partition() and offset() getters to make them consistent with their implementations (ref)

Problem

Users were unable to create synthetic Message objects in their unit tests and had to resort to reading Message objects from a live Kafka cluster.

>>> import confluent_kafka
>>> confluent_kafka.Message()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'cimpl.Message' instances

Solution

A constructor has been defined in the Message class. All params have been intentionally kept optional to support easy instantiation without providing any params. This way of creating new messages is expected to be used only while writing unit tests. Producers and consumers will continue to use the internal factory method (Message_new0) for creating message objects.

>>> import confluent_kafka
>>> confluent_kafka.Message()
<cimpl.Message object at 0x101301640>
>>> 

Checklist

• Contains customer facing changes? Including API/behavior changes
• Did you add sufficient unit test and/or integration test coverage for this PR?

References

#1535

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

[MSeal]

Thanks for adding tests covering various init behaviors

[sonarqube-confluent]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube

[pranavrth]

Message class was intentionally like this because we didn't want user to instantiate a message. There are some APIs which take message as input like commit and store_offsets.

We can choose from the below:

• We provide a MockMessage class instead of making it instantiable.
• We add make this instantiable in other clients as well and test all the APIs that uses messages as input.

[MSeal]

@pranavrth I advised against the Mock providing here as it won't solve the root issues and this is a non-default sharp edge that the user can be responsible for if they misuse. I suggested we either do checks on the init or checks in method uses to ensure bad inputs raises a clean exception if we want to prevent deep failures from bad inputs. But I also imagine 90% of the cases here will be user knowingly instantiating an object they know isn't real for e2e patterns.