*Motivation*

The getSchema logic in Pulsar proxy handler doesn't handle the case that
the request doesn't have schema version.

*Modification*

- Fix the logic to handle the case that a GetSchema request doesn't have schema version.
- Forward the GetSchemaResponse back to the client

*Tests*

The GetSchema tests in ProxyTest was disabled by mistake. Turn it on.
(cherry picked from commit 676fd71a)

* o.a.p.c.api -> o.a.p.c.protocol

Classes in pulsar-common module were moved to avoid jpms split-package
conflict between the pulsar-client-api and pulsar-common modules.

* o.a.p.c.schema -> o.a.p.c.protocol.schema

Classes in pulsar-common module were moved to avoid jpms split-package
conflict between the pulsar-client-api and pulsar-common modules.

### Motivation
In order to support #3742 #3876.
Now, proxy handle ProxyLookupRequests don't support GetSchema.

### Modifications
Add the getSchema method implementation in ProxyConnection 

### Verifying this change
Add new a test in ProxyTest testGetSchema()

### Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (yes)
The admin cli options: (no)
Anything that affects deployment: (no)
### Documentation
Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (no)
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

Allow non-pesistent topics to be retrieved along with persistent ones from the "GetTopicsOfNamespace" method (#2025)

### Motivation

Please see issue #2009 for a detailed bug report.

In our use case we require using java client with pattern subscription to read from a set of non-persistent topics. Unfortunately, right now this feature doesn't work. After researching the cause for this I have found out that under the hood the client is requesting a list of topics by namespace from the server and then filters them out by pattern and subscribes to them. The method in Pulsar broker NamespaceService class that is responsible for searching for required topics only uses ledgers, thus returning only persistent topics to the client. The goal of this pull request is to provide a solution for that problem.

### Modifications

This pull request updates `getListOfTopics` method of NamespaceService class to also include active non-pesistent topics from local broker cache inside the `multiLayerTopicsMap` collection of BrokerService in the result.

### Result

As a result, requesting a list of topics by namespace using the HTTP API or binary API (and thus via the clients) will add non-persistent topics to search result, allowing pattern subscription to be used with non-persistent topics.

### Considerations

1. Since this method pulls non-persistent topics from local broker cache, this probably means that this solution will only work for Pulsar installations with a single broker. And if there are multiple brokers, results might be inconsistent. Unfortunately I don't really know if non-persistent themselves work in multi-broker setups. I have recently asked on Slack if non-persistent topics are being replicated in any way and @merlimat's response was that they don't. Also it seems to be that some other methods that are working with non-persistent topics are using this very same collection.

2. It seems to me that unit tests have made sure that Java client can work with this setup, but this might still be a breaking change for other clients or if applications working with this API are not expecting non-persistent topics in result.

3. I have made sure that old unit tests inside the `pulsar-broker` subproject are still working and updated some old tests for this particular use case. Are there any more tests that I can add.

Overall, we really need this and I would appreciate if maintainers could share their opinion. Thanks in advance.

* Fix regex

* Implement GetTopicsOfNamespace on Proxy

* remove unneeded import

* Add pluggable authorization service

fix: move FutureUtils to common and fix import

add grantpermission api

take default auth method

pass authData to authorization provider

keep single authorization provider

* fix rebase change