### Motivation

We are using Athenz for client authentication. Occasionally, the following error occurs and client authentication fails.

> [pulsar-web-28-7] ERROR com.yahoo.athenz.auth.token.Token - Token:validate: token=v=Z1;d=xxx;r=xxx;p=xxx;a=xxx;t=1544027514;e=1544034714;k=0;i=xxx.xxx.xxx.xxx : has future timestamp=1544027514 : current time=1544027513 : allowed offset=0

This means that the timestamp included in the authentication token is more future than the server time. Since the difference between them is only 1 second, I think that the time of either server or client is slightly off.

This error can be avoided by increasing the value of `allowed offset`. Currently, this value is set to 0 in Pulsar, but the default value in Athenz ZMS seems to be 300 seconds.
https://github.com/yahoo/athenz/blob/93fe62c17f3ab4556c71c5136c1646df4a874a5f/servers/zms/conf/zms.properties#L277-L280

### Modifications

* Changed the default value of `allowed offset` from 0 to 30 (I think 300 seconds is too long)
* Enabled specifying `allowed offset` using system property

### Result

Even if the time of the server or client is slightly off, the authentication will succeed.

* [bookkeeper] bump bookkeeper version to 4.7.3

*Motivation*

There are bunch of fixes in 4.7.3 regarding dns cache, ledger storage flushes.
4.7.3 is a minor release of 4.7.2, so it is safe to upgrade and included in 2.2.1 release

* Fix compilation issue

* update license

* Python Client: fix `Consumer.unsubscribe`

Fix a typo in `self._consumer.unsubscribe`

* Python Client: test `Consumer.unsubscribe`

When we run `pulsar-client-cpp/docker/create-images.sh`, the following six docker images are created.
```
pulsar-build:manylinux-cp27-cp27mu
pulsar-build:manylinux-cp27-cp27m
pulsar-build:manylinux-cp34-cp34m
pulsar-build:manylinux-cp35-cp35m
pulsar-build:manylinux-cp36-cp36m
pulsar-build:manylinux-cp37-cp37m
```
These images are pushed to Docker Hub when `pulsar-client-cpp/docker/push-images.sh` is executed. But `pulsar-build:manylinux-cp37-cp37m` not included in the target.

https://github.com/apache/pulsar/blob/7bbcc72f5a2690da701c299856ff0d2b62eed5d9/pulsar-client-cpp/docker/create-images.sh#L26-L33
https://github.com/apache/pulsar/blob/7bbcc72f5a2690da701c299856ff0d2b62eed5d9/pulsar-client-cpp/docker/push-images.sh#L28-L34

* Update libcurl version included in docker images

* Drop python 3.3 support

Motivation
We may meet NPE like this:
```
java.lang.NullPointerException: null
at org.apache.pulsar.common.api.proto.PulsarApi$KeyValue$Builder.setValue(PulsarApi.java:1923) ~[org.apache.pulsar-pulsar-common-2.1.1-incubating.jar:2.1.1-incubating]
```
This is related to protobuf, it does not support null-able field directly.
protocolbuffers/protobuf#1606

In this fix we try to avoid this by add checking before this method is called.

* Add bookkeeper service and other fixes

- Add the topologyKey for the pod affinity for bookies
- Fixed a misspelling in the name of the ledgers disk
- Fixed the selector in the proxy service to select proxy pods
Signed-off-by: NByron Ruth <b@devel.io>

* Update bookkeeper service comment to note DNS
Signed-off-by: NByron Ruth <b@devel.io>

* Enable SSL of LibCurl linked to C++ library

* Update openssl versions

* Update openssl to 1.1.0j

### Motivation

In some cases the broker can immediately gets assigned traffic before it's fully boostrapped. 

This happens because the load manager is registering the broker in ZK before some of the initialization steps are completed. 

This results in NPE, like : 

```
Caused by: java.lang.NullPointerException
	at org.apache.pulsar.broker.service.persistent.PersistentTopic.hasSchema(PersistentTopic.java:1815) ~[org.apache.pulsar-pulsar-broker-2.2.0-streamlio-22.jar:2.2.0-streamlio-22]
	at org.apache.pulsar.broker.service.ServerCnx.lambda$25(ServerCnx.java:836) ~[org.apache.pulsar-pulsar-broker-2.2.0-streamlio-22.jar:2.2.0-streamlio-22]
	at java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:656) ~[?:1.8.0_181]
```

### Modifications

 * Register the broker in ZK only after the full start sequence has been done. This will ensure other brokers will not discover this broker before it's ready.
 * Expose the "is ready" state in the VipStatus -- This will be used to make sure the load balancer will not direct any lookup request to the broker before it's ready.

*Motivation*

java.lang.IllegalStateException is thrown sometime when pulsar-admin connects through a pulsar proxy.

```
06:10:42.202 [pulsar-external-web-60] WARN  org.eclipse.jetty.io.SelectorManager - Exception while notifying connection HttpConnectionOverHTTP@3781919f::SocketChannelEndPoint@3946791f{prod-broker-2.prod-broker.default.svc.cluster.local/192.168.228.141:8080<->/192.168.122.159:41496,OPEN,fill=FI,flush=-,to=1/30000}{io=1/1,kio=1,kro=8}->HttpConnectionOverHTTP@3781919f(l:/192.168.122.159:41496 <-> r:prod-broker-2.prod-broker.default.svc.cluster.local/192.168.228.141:8080,closed=false)=>HttpChannelOverHTTP@3d79faef(exchange=HttpExchange@787b7324 req=PENDING/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@43cd18dd(req=BEGIN,snd=SENDING,failure=null)[HttpGenerator@49490f3a{s=START}],recv=HttpReceiverOverHTTP@3b153a7e(rsp=IDLE,failure=null)[HttpParser{s=START,0 of -1}]]
java.lang.IllegalStateException: The same org.eclipse.jetty.client.AsyncContentProvider instance cannot be used in multiple requests
    at org.eclipse.jetty.client.util.DeferredContentProvider.setListener(DeferredContentProvider.java:117) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpSender.send(HttpSender.java:207) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.http.HttpChannelOverHTTP.send(HttpChannelOverHTTP.java:85) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpChannel.send(HttpChannel.java:128) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpConnection.send(HttpConnection.java:201) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.http.HttpConnectionOverHTTP$Delegate.send(HttpConnectionOverHTTP.java:253) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.send(HttpConnectionOverHTTP.java:122) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.http.HttpDestinationOverHTTP.send(HttpDestinationOverHTTP.java:38) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:347) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpDestination.process(HttpDestination.java:305) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpDestination.send(HttpDestination.java:295) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.HttpDestination.succeeded(HttpDestination.java:229) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.AbstractConnectionPool.proceed(AbstractConnectionPool.java:154) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.AbstractConnectionPool$1.succeeded(AbstractConnectionPool.java:132) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.AbstractConnectionPool$1.succeeded(AbstractConnectionPool.java:124) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.util.Promise$Wrapper.succeeded(Promise.java:130) ~[org.eclipse.jetty-jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onOpen(HttpConnectionOverHTTP.java:130) ~[org.eclipse.jetty-jetty-client-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324) [org.eclipse.jetty-jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:254) [org.eclipse.jetty-jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.io.ManagedSelector.access$1800(ManagedSelector.java:61) [org.eclipse.jetty-jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830]
    at org.eclipse.jetty.io.ManagedSelector$CreateEndPoint.run(ManagedSelector.java:886) [org.eclipse.jetty-jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_181]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_181]
    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
```

The race condition happens somewhere in setting listener. However I have no idea how the race condition
happens. so change to use ProxyServlet to avoid this race condition.

*Changes*

Change AsyncProxyServlet to ProxyServlet

* Handle unknown runtime exception while reading entries

* make asyncReadEntry0 private

* Add partitioned-topic stats internal admin-api

* add class

* Fixed race condition in schema initialization in partitioned topics

* Removed lombok log

* Fixed tests

* Upgrade commons-collections for Security Vulnerabilities[CVE-2015-7501]

* fix license

* fix license

* Fixed ZLib decompression in C++ client

* Make symbol visible for unit tests

* Also include namespace into pragma directive

* Also expose symbols for CompressionCodec

* fix consume messages in partitioned topics on websocket

* add consumeMessagesInPartitionedTopicTest

* add fromByteArrayWithTopic

* remove public

* Make proxy advertise protocol version of client to broker

* Revert incorrect change