Parent Issue

Part of #315 (TCP receive std::span callback migration)

Summary

Align secure_tcp_socket receive path with the new std::span<const uint8_t> callback approach to eliminate per-read std::vector allocations/copies and avoid holding locks while invoking callbacks.

Background

secure_tcp_socket::do_read() currently:

• Builds std::vector<uint8_t> chunk(...) per read from read_buffer_ (src/internal/secure_tcp_socket.cpp:118 vicinity)
• Uses callback_mutex_ while invoking callbacks (risking contention and making callback latency visible to other operations)

Proposed Solution

1) Add view-based receive callback API

Add a new registration API:

• set_receive_callback_view(std::function<void(std::span<const uint8_t>)> cb)

Contract:

• Span valid only until callback returns.

2) Keep legacy vector callback for compatibility

Keep the existing vector-based callback API and preserve semantics.

Dispatch rule:

• Prefer view callback when set (no allocation/copy)
• Otherwise fall back to vector callback (copy into vector)

3) Remove locking from the hot path

Switch callback storage/access to lock-free shared_ptr + atomic_load/atomic_store.

Files to Update

• src/internal/secure_tcp_socket.cpp
• include/kcenon/network/internal/secure_tcp_socket.h

Acceptance Criteria

• secure_tcp_socket exposes set_receive_callback_view(std::span<const uint8_t>)
• When view callback is used, no per-read std::vector allocation/copy occurs in do_read()
• Callback invocation does not hold callback_mutex_
• Legacy callback continues to work unchanged
• Unit/integration tests pass

Test Plan

• Build and run:
  • ctest --output-on-failure
• If TLS integration tests exist, run secure-path coverage (client/server handshake + receive)