KAFKA-13022: Optimize ClientQuotasImage#describe

[FrankYang0529]

In previous implementation, the ClientQuotasImage#describe goes through all ClientQuotaEntity and checks whether entity type and entity name are matched the filter. In this PR, it goes through all ClientQuotaEntity#entries in the constructor and build a new data structure Map<String, Map<String, Set<Entry<ClientQuotaEntity, ClientQuotaImage>>>>. The first layer is entity type. There are only three entity types: user, client-id, and ip. The second layer is entity name. The last layer is a set of matched entries. With this data structure, we can speed up describe function.

Correctness is covered by ClientQuotasRequestTest.

Benchmark result:

• trunk

  Benchmark                                             (eachEntityCount)  Mode  Cnt      Score   Error  Units
  ClientQuotasImageDescribeBenchmark.describeDefault                   10  avgt    2    422.020          ns/op
  ClientQuotasImageDescribeBenchmark.describeDefault                  100  avgt    2   4380.829          ns/op
  ClientQuotasImageDescribeBenchmark.describeDefault                 1000  avgt    2  54567.929          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                     10  avgt    2    461.441          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                    100  avgt    2   4620.061          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                   1000  avgt    2  55275.026          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified                 10  avgt    2    651.988          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified                100  avgt    2   5477.147          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified               1000  avgt    2  60935.943          ns/op
  

• branch

  Benchmark                                             (eachEntityCount)  Mode  Cnt      Score   Error  Units
  ClientQuotasImageDescribeBenchmark.describeDefault                   10  avgt    2     10.666          ns/op
  ClientQuotasImageDescribeBenchmark.describeDefault                  100  avgt    2     11.317          ns/op
  ClientQuotasImageDescribeBenchmark.describeDefault                 1000  avgt    2     11.409          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                     10  avgt    2     68.551          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                    100  avgt    2     61.202          ns/op
  ClientQuotasImageDescribeBenchmark.describeExact                   1000  avgt    2     65.592          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified                 10  avgt    2    366.921          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified                100  avgt    2   4135.522          ns/op
  ClientQuotasImageDescribeBenchmark.describeSpecified               1000  avgt    2  52720.811          ns/op
  

[ahuang98]

personally this logic seems really hard to follow, especially with all the stacked for loops. I think some code comments would really help!

[ahuang98]

nit: local vars to reduce redundant gets and improve readability?

[ahuang98]

does this have to equal exactMatch as long as entry.getKey().entries() are encompassed by both typeMatch and exactMatch?