libcam,cam-service: Make TCP socket more responsive

A current issue happening on the CI is that the cam-service is
spending a considerable amount of time on the recv() after the
CAM packet header is received, leading to a timeout of the
timer that expects some packet by the cam-app-example.

On the cam-app-example side, the packet is sent in one time
on the TCP stream, so this narrows down the issue on the TCP
stream handling.

TCP is a complex protocol that tries to maximize the efficiency
and so it's not tuned for a small amount of data that needs to be
received timely, it usually tries to put together most of the
data to be sent and tries to send the less possible amount of ACK,
putting them together in one go when it really needs.

All of this is delaying the receive (and send) of the CAM packets
into the TCP stream, leading to the above issue.

To handle that, this commit is disabling TCP Nagle algorithm in
order to send immediately the data when requested and it is also
disabling the TCP delayed ack, in order to don't wait for more data
before sending a broader acknowledgment and have the protocol more
responsive for smalls amount of data in transit. The Zephyr
implementation won't need to disable the TCP delayed ack because the
RTOS doesn't implement it.

Furthermore, network stack implementations can have different queues
depending on the Type Of Service of the IP packet, so for the CAM
packets set the low delay TOS on the Linux implementation, so that
the receiving system knows that it needs to be prioritized.
The current Zephyr code doesn't seems to implement any mechanism for
different TOS, so don't set it for Zephyr.

Add missing word to the dictionary to please the spell checker.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>