[CLIENT-5193] Fix leak when receiving AS_BYTES_PYTHON-type values from the server

[juliannguyen4]

Fix bug where AS_BYTES_PYTHON are returned as bytes instead of bytearrays

This seems to be affecting customers in production, so I would like to merge this in ASAP

TODO

• Mention co-author in commit description

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.38%. Comparing base (285f8f1) to head (3528049).

Files with missing lines	Patch %	Lines
src/main/serializer.c	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #1180      +/-   ##
==========================================
- Coverage   85.39%   85.38%   -0.01%     
==========================================
  Files         101      101              
  Lines       14614    14615       +1     
==========================================
  Hits        12479    12479              
- Misses       2135     2136       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[juliannguyen4]

Local repro with 19.2.2

==7804== 61 (56 direct, 5 indirect) bytes in 1 blocks are definitely lost in loss record 1,215 of 1,777
==7804==    at 0x4885250: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==7804==    by 0x506B0B: _PyObject_New (object.c:319)
==7804==    by 0x4BB03B: PyByteArray_FromStringAndSize (bytearrayobject.c:125)
==7804==    by 0x579855F: deserialize_based_on_as_bytes_type (serializer.c:423)
==7804==    by 0x577509F: val_to_pyobject (conversions.c:1725)
==7804==    by 0x5775673: bins_to_pyobject_each (conversions.c:2099)
==7804==    by 0x57ECC4B: as_record_foreach (as_record.c:463)
==7804==    by 0x5774BFB: bins_to_pyobject (conversions.c:2128)
==7804==    by 0x5774E7F: record_to_pyobject (conversions.c:1955)
==7804==    by 0x5762C47: AerospikeClient_Get_Invoke (get.c:99)
==7804==    by 0x5762D23: AerospikeClient_Get (get.c:171)

[juliannguyen4]

Verified locally that the leak no longer appears in valgrind

Local build is aerospike-19.3.0.dev27+5.g352804928-cp312-cp312-linux_aarch64.whl

NOTE - there's some failing jobs because I cancelled them and the status reported as "failing", and the linkcheck job is still flakey