expose full response in write client call

[nxlouie]

The current python client today exposes just the rows_affected integer - which seems to be from where delete by filter was introduced

We specifically want to track x-turbopuffer-billing-bytes-written metric on our end to get a more granular look at where our costs are coming from, and just returning the response holistically could just help expose all the metrics the raw api provides at once

[benesch]

Hey @nxlouie—thanks for putting this up! Definitely want to get you access to those additional billing metrics via the Python SDK. I'm a bit leery of exposing the response directly though, as it's a lower level object that we don't currently expose at the Namespace method level.

As a brief aside, we're working on rolling out our v2 query API this week, which will return a response body like this:

// Request: POST /v2/namespaces/:ns/query
// Response:
{
  "rows": [
    {"dist": 0.001539588, "id": 2}
    {"dist": 0.005690813, "id": 3}
  ],

  "performance": {
    "cache_hit_ratio": 1.0,
    "cache_temperature": "hot",
    "servel_total_ms": 105,
    "query_execution_ms": 105,
    "exhaustive_search_count": 3
  },
  
  "billing": {
    "billable_logical_bytes_queried": 256000000,
    "billable_logical_bytes_returned": 24
  }
}

I think we may want to change the v2 write API to have a similar response body. Maybe something like this:

{
    "rows_affected": /* ... */,
    "performance": { /* ... */ },
    "billing": {
        "billable_logical_bytes_written": /* ... */
    }
}

Then we'd change Namespace.write to return the whole response body (response['content']), but not the full response. That would get you access to the fields you need (and any similar fields we add in the future) while keeping the type high level.