GH #562: Remove config dependency on ZooKeeper (not ZooKeeper the service)

[awalther28]

Looking into the single test failure but wanted folks input while investigating. Looks like the same test is consistently failing in master as well 🤔 (link to master semaphore tests)

This PR addresses #562. It proposes the following:

• remove schema registry's zookeeper dependency in docker-compose
• swap SCHEMA_REGISTRY_KAFKASTORE_CONNECTION_URL: 'zookeeper:2181' for SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: 'PLAINTEXT://broker:9092'
• alter test for merging/ksql DESCRIBE EXTENDED diff check
  • investigation with @bbejeck into the matter, appears changes to configs cause expected behavior (local running stats weren't printed out previously and now they are)

[gAmUssA]

💯 for removing zookeeper config in SR!

[ybyzek]

🏅 @awalther28 great improvement across the board. Left 2 comments: one missed ZK connect param that can be deleted, and one for consideration.

[ybyzek]

There is one more tutorial that refers to something ZooKeeper-related:

_includes/tutorials/connect-add-key-to-source/kstreams/code/docker-compose.yml:      CONNECT_LOG4J_LOGGERS: org.apache.zookeeper=ERROR,org.I0Itec.zkclient=ERROR,org.reflections=ERROR      

Background: I wrote that tutorial and borrowed that configuration line from other GitHub examples. Admittedly, this was a copy/paste, and so I don't know its purpose or what the impact would be to remove it.

Do we know if that needs to be there? Would org.reflections=ERROR be sufficient?

Or is this a trivial/moot point because ZK can still be removed from Docker Compose (with KIP-500) and this would continue to work?

[awalther28]

@ybyzek to your question about log4j filters... given the lack of reply from the connect team and use of those zk filters in other contexts, do we want to keep them for the time being?

[ybyzek]

@awalther28 agree, let's leave them as-is.

[bbejeck]

As discussed offline with @awalther28 the failure is unrelated to this PR.