[CLIENT-4834] Fix memory error when shared memory is enabled and server version is read before sending user agent string

[juliannguyen4]

Testing

b957531 shows that a crash occurs.
8bba73b (the following commit) shows that the crash is fixed by the c client.

• Build artifacts passes
• Valgrind shows no memory errors or leaks from these changes
• Massif memory usage looks ok. (TODO need to compare with branch that has the same code changes but without the new tests to verify that only the latter is causing massif memory to increase)

Out of scope

• shm_key client config default was changed... also address other C client api changes

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.44%. Comparing base (f1af021) to head (7f53799).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev    #1067   +/-   ##
=======================================
  Coverage   84.44%   84.44%           
=======================================
  Files          99       99           
  Lines       14062    14062           
=======================================
  Hits        11874    11874           
  Misses       2188     2188           

☔ View full report in Codecov by Sentry.
📢 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]

1. New shared memory tests are failing on this feature branch when run locally with a locally built wheel.

FAILED new_tests/test_shared_memory.py::TestSharedMemory::test_one_client - exception.ClientError: (-1, 'Shared memory get failed: Invalid argument pid: 3370468', 'src/main/aerospike/as_shm_cluster.c', 920, False)
FAILED new_tests/test_shared_memory.py::TestSharedMemory::test_multiple_clients - exception.ClientError: (-1, 'Shared memory get failed: Invalid argument pid: 3370468', 'src/main/aerospike/as_shm_cluster.c', 920, False)

Resolved by deleting the existing shared memory segment locally. But when rerunning without deleting the shared memory segment, a crash occurs.

• Crash doesn't occur when using unoptimized build

• This behavior also happens if only running "test_one_client" test case

• Updating hardcoded SHM key in python client to the default one in the c client does not fix this crash

• When debugging with GDB, config->shm_key looks correct

2. Using branch CLIENT-4834-test-without-fix, was unable to reproduce memory error on github actions, but can reproduce it locally with that branch and a locally built wheel

[juliannguyen4]

I see a new "definitely lost" memory leak in this branch:

==4707== 87,455 (7,608 direct, 79,847 indirect) bytes in 1 blocks are definitely lost in loss record 3,809 of 3,809
==4707==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4707==    by 0x98F06A8: CRYPTO_zalloc (in /opt/hostedtoolcache/Python/3.10.20/x64/lib/python3.10/site-packages/aerospike.libs/libcrypto-ad2cd6c1.so.3)
==4707==    by 0x965BCD3: SSL_new (in /opt/hostedtoolcache/Python/3.10.20/x64/lib/python3.10/site-packages/aerospike.libs/libssl-7d9e47d9.so.3)
==4707==    by 0x9309B31: as_tls_wrap (as_tls.c:886)
==4707==    by 0x9306B23: as_socket_wrap (as_socket.c:169)
==4707==    by 0x9306BC3: as_socket_create (as_socket.c:151)
==4707==    by 0x92F444F: as_node_try_family_connections (as_node.c:435)
==4707==    by 0x92F4B5A: as_node_create_socket (as_node.c:482)
==4707==    by 0x92F6796: as_node_create_connection (as_node.c:527)
==4707==    by 0x92F6C32: as_node_get_connection (as_node.c:687)
==4707==    by 0x92EAEA9: as_info_command_node (as_info.c:126)
==4707==    by 0x92B7D8D: aerospike_info_foreach (aerospike_info.c:174)

Valgrind run with only the C client changes in this branch. The tests here are the same as in dev: https://github.com/aerospike/aerospike-client-python/actions/runs/26589918598/job/78346288223

A memory leak occurs similar to the one above:

==4609== 79,977 (7,608 direct, 72,369 indirect) bytes in 1 blocks are definitely lost in loss record 3,806 of 3,806
==4609==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4609==    by 0x98F06A8: CRYPTO_zalloc (in /opt/hostedtoolcache/Python/3.10.20/x64/lib/python3.10/site-packages/aerospike.libs/libcrypto-ad2cd6c1.so.3)
==4609==    by 0x965BCD3: SSL_new (in /opt/hostedtoolcache/Python/3.10.20/x64/lib/python3.10/site-packages/aerospike.libs/libssl-7d9e47d9.so.3)
==4609==    by 0x9309B31: as_tls_wrap (as_tls.c:886)
==4609==    by 0x9306B23: as_socket_wrap (as_socket.c:169)
==4609==    by 0x9306BC3: as_socket_create (as_socket.c:151)
==4609==    by 0x92F444F: as_node_try_family_connections (as_node.c:435)
==4609==    by 0x92F4B5A: as_node_create_socket (as_node.c:482)
==4609==    by 0x92F6796: as_node_create_connection (as_node.c:527)
==4609==    by 0x92F6C32: as_node_get_connection (as_node.c:687)
==4609==    by 0x92EAEA9: as_info_command_node (as_info.c:126)
==4609==    by 0x92B7D8D: aerospike_info_foreach (aerospike_info.c:174)

Valgrind run in dev does not have this memory leak: https://github.com/aerospike/aerospike-client-python/actions/runs/26546398325/job/78199345990

EDIT: I saw this memory leak in dev, albeit it doesn't show up all the time. I think it's a good sign this leak doesn't come from this branch.