Refactoring and updates for 2024-10 API spec

[jhamon]

Problem

Needed to consume the 2024-10 API spec.

Solution

The spec updates involved many changes to operation ids. This should not touch the user experience, but does mean this diff is somewhat larger than usual due to the large number of tests for existing functionality that needed to be adjusted for the new names:

• upsert > upsert_vector
• fetch > fetch_vectors
• query > query_vectors
• delete > delete_vectors
• list > list_vectors
• start_import > start_bulk_import
• describe_import > describe_bulk_import
• etc

Other changes

Cleanup prerelease code no longer needed

• Deleted pinecone/core_ea/ which was the home of some code generated off of the 2024-10 spec when bulk import functionality was in a pre-release state. We no longer need this. That's why this PR has 21k lines removed.

Changes to generation process

• Placed a copy of classes such as ApiClient, Endpoint, ModelNormal, etc which were previously generated into a new folder, pinecone/openapi_support. Even though these used to be generated, they contain no dynamic content. So taking them out of the generation process should make it significantly easier to work on core improvements to the UX and performance of the generated code, since the source of truth will no longer be a mustache file (FML)
• Updated the codegen script ./codegen/build-oas.sh 2024-10 false to delete instead of de-dupe copies of shared classes like ApiClient, and edit model+api files that continue to be generated to find the classes they need in the new openapi_support folder.

mypy fixes

• I needed to make adjustments in some openapi_support classes to satisfy the mypy type checker (pinecone/core has been ignored in the past, and our goal should be to eventually have 100% of code typechecked).
• Wrote some initial unit tests to characterize some of the behavior in ApiClient. The tests were to help give me more confidence I wasn't breaking something along the way while making adjustments for mypy.
• Added a dev dependency on a package with types for datetime

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)

[aulorbe]

I thought we were not using the word "bulk" in the clients anymore wrt to this endpoint? https://pinecone-io.slack.com/archives/C05MYEX7T2L/p1728935415605249?thread_ts=1728935400.761069&cid=C05MYEX7T2L

cc @austin-denoble

[aulorbe]

(Looks like it's not used in apis either: e.g. https://github.com/pinecone-io/apis/blob/main/static/2024-10/db_data_2024-10.oas.yaml#L76)

[austin-denoble]

This is generated code, so not really publicly exposed. I think this is fine, there's a similar story in other SDKs since the spec contains "bulk" in a few places.

[aulorbe]

I think we need to remove "bulk" from the import language. See here #401 (comment) and here https://pinecone-io.slack.com/archives/C06D0HAKG9F/p1728921416752599?thread_ts=1728663784.981229&cid=C06D0HAKG9F

[rohanshah18]

Is inference going to be a part of the plugin?

[jhamon]

For now, inference stuff comes in via plugin which is why you don't see anything about it here.

[rohanshah18]

Left a question about inference. Otherwise it looks good, LGTM!