The __HAL_LOCK() macro that you show is indeed problematic because it never blocks, so it could make your application hang.
The macro’s __HAL_LOCK() and __HAL_UNLOCK() won’t do much unless you’re accessing the same handle from multiple tasks.
Within the NetworkInterface there is a rule: the EMAC peripheral and the PHY may be accessed by the IP-task until the prvEMACHandlerTask() has started and takes control.
In order to save RAM you can disable the TCP sliding window mechanism:
#define ipconfigUSE_TCP_WIN 0
You can decrease the size of a maximum packet:
#define ipconfigNETWORK_MTU 512
Use BufferAllocation_2.c in stead of BufferAllocation_1.c.
You can play with ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS. The optimal value should be assessed by running you application while checking uxGetMinimumFreeNetworkBuffers() and uxGetNumberOfFreeNetworkBuffers().
You could define the following in your FreeRTOSIPConfig.h:
#define iptraceFAILED_TO_OBTAIN_NETWORK_BUFFER() configASSERT( 0 )
which means that the application will halt as soon as it is running out of network buffers.
Only define this macro while testing, not in a real-life application.
About the network driver: I wonder if it would be possible to add support for STM32F107 in the existing STM32Fx driver.
And if not, I would like to check the driver that you are using.