Fix race condition in stream buffers when priority(IP task)==priority(task using TCP/IP)

[AniruddhaKanhere]

Description

When the priority of the TCP/IP stack and the priority of the task using TCP/IP stack are equal AND when the task in question is using the recv function, then there is a possible race condition that exists in the stream buffers which lead to advertisement of 0 window.
This PR fixes that by adding a critical section around the stream buffer member update section.

Test Steps

Related Issue

This problem was reported by Shayan Mukhtar in this post on the FreeRTOS forum.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[AniruddhaKanhere]

/bot run uncrustify

[htibosch]

@AniruddhaKanhere wrote:

... when the task in question is using both send and recv functions

A small correction: there was a race condition between the IP-task and the task that calls recv().
The transmission stream works independently.

And maybe it is also worth telling that the problem was reported by Shayan Mukhtar in this post on the FreeRTOS forum.

To summarise the problem once more: the members uxHead and uxFront must be updated together, in a single atomic operation. Suspend/resume will be called from the IP-task only.

The solution was tested and I approve it.

Thank you

[AniruddhaKanhere]

@htibosch, I updated my description. Thanks for pointing that out.