Refactor: partition_assignment_strategy to accept enumerated values

[kares]

this is follow-up from: #16 where a partitioner option got introduced which enumerates a list of supported values and maps them to Java class names.

a few Kafka customization options accept class names instead of enumerated values.
IMO this makes the configuration a bit ugly and closely tied to Kafka's client API details.
(e.g. value_serializer => 'org.apache.kafka.common.serialization.StringSerializer')

so here's a review of those, turns out that only one setting partition_assignment_strategy supports multiple values wout a default so it has been refactored to accept an enumerated list of values, which are documented, while also allowing for class-names due compatibility..

options such as key_serializer, value_serializer have a default or do not have much variability, so I've left those as they are for now.

also some docs rendering fixes incorporated (for pending 10.1.0 release)

[andsel]

I've put some little notes, but generally LGTM
Do you think that a unit test on method partition_assignment_strategy_class could help to avoid future regressions?

[kares]

Thanks Anread, will look into addressing your concerns.

Do you think that a unit test on method partition_assignment_strategy_class could help to avoid future regressions?

I believe the functional (integration) spec we have is sufficient, since Kafka will try to instantiate the class set from configuration. Of course could the spec could be improved to test specifics of each strategy but a unit spec is a bit cumbersome since we could only assert on class names.

[yaauie]

+1 to usability for the usual cases.

Are there cases in the wild where users provide their own ConsumerPartitionAssignor implementations? Do we need to document that the fully-qualified path to a class may still be used?

[kares]

Are there cases in the wild where users provide their own ConsumerPartitionAssignor implementations?

there probably aren't since we do not allow loading custom .jar files.
in theory, there might be if users add stuff to class-path themselves.

Do we need to document that the fully-qualified path to a class may still be used?

this also came up during #16 as a partitioner => ... option was added with enumerated values (also accepting class-names). we have the custom class name documented but I think we should remove that part:

The configuration also allows setting a partitioner class name
e.g. org.apache.kafka.clients.producer.UniformStickyPartitioner.

so just like here I am for NOT documenting the possibility to set a class-name (unless we're requested to support loading custom classes).