gRPC: parse_query_response: Skip parsing empty Usage

[daverigby]

Problem

When parsing the result of a gRPC query() call, we unconditionally
create a Usage model object, even if no usage information was returned
(e.g. non-serverless index).

Solution

This adds a small but not insignificant cost to every query() call -
mostly due to the fact we use OpenAPI auto-generated model code for
the Usage and QueryResponse objects.

Benchmarks using a simple PineconeGRPC-based program making query()
calls against a p2.x4 pod show a 1.05x improvment in QPS by only
constructing a Usage class (and associating it to QueryResponse) if a
'usage' field is present in the protobuf response:

Before:

Type     Name                                                                          # reqs      # fails |    Avg     Min     Max    Med |   req/s  failures/s
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
grpc     query_pinecone_no_filter                                                        3223     0(0.00%) |     17      17     139     18 |   55.01        0.00
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------

After:

Type     Name                                                                          # reqs      # fails |    Avg     Min     Max    Med |   req/s  failures/s
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
grpc     query_pinecone_no_filter                                                        3408     0(0.00%) |     17      16      96     17 |   57.55        0.00
--------|----------------------------------------------------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Infrastructure change (CI configs, etc)
• Non-code change (docs, etc)
• None of the above: (explain here)

Test Plan

• Existing unit tests
• Tested manually against pinecone-field/pinecone-stress-test