Use type safe structures to configure the consumer

[cbornet]

• Use ConsumerBuilderCustomizer to customize the consumer when creating it
• Remove BatchReceivePolicy from the createConsumer params as it can now be configured through ConsumerBuilderCustomizer
• Add method createConsumer(Schema<T> schema, Collection<String> topics, Map<String, String> properties, List<ConsumerBuilderCustomizer<T>> customizers) to be able to replace the topics and the consumer properties (the builder methods can only add to the default).
• Set ackTimeoutMillis to 1000 instead of 1 in tests as the ack timeout must not be below 1 second (and now it's checked by the code 🙂)

[onobc]

@cbornet thanks for this code proposal. I am all for using the type-safe configuration options but I am wondering if the benefits are outweighing the drawbacks at this point.

Concern 1 - added field mappings

The manual mappings (aka the heroics) we are having to do in the DPMLC and the DPCF may outweigh the benefits of this type-safe change. I do realize some of this is due to bugs in the config data impl and will eventually be addressed.

Concern 2 - is config data public?

In digging around for the client and producer config data side of things, I noticed that all of these config datas are in the "impl" package and are not exposed by the interfaces. They are only exposed by the default implementations. I believe this is the reason there is only a loadConf(Map) and not a loadConf(<type>ConfigurationData). I think before going forward we need to be sure that the config data is considered part of the public API. It does not seem that way to me after digging in a bit.

I reviewed all of the changes except for the tests/**. I want to wait until we talk about the above concerns before I invest in reviewing the tests (but mostly because it is late now 😄 )

[cbornet]

You're totally right that ConsumerConfigurationData is part of the client impl so it probably shouldn't be used outside of the pulsar-client internal.
There used to be a ConsumerConfiguration in the API but it's deprecated.
I see 3 options:
1/ Create a conf structure in spring-pulsar. It could have fluent setters and optional values. Mapping code would still be needed.
2/ Use a ConsumerBuilderCustomizer in the DefaultPulsarConsumerFactory
instead of ConsumerConfigurationData. And also give the possibility to set default topicNames and properties that can be overriden later in createConsumer.
3/ Create a DefaultPulsarConsumerFactoryBuilder that can take set every prop individually.

My preference goes to option 2/

[onobc]

Superseded by #192