Compat: pthread.h shim for FreeRTOS

[projectgoav]

As discussed in #960.

Assumes that anyone wishing to build for FreeRTOS will define FREERTOS and ensure that the FreeRTOS headers are added to the include path at FreeRTOS/___

---

pthread_once

I wasn't sure if this has to be thread-safe. Can easily adjust this if required.

Syslog Support

I had to adjust the compat/syslog.h slighty to account for more than just Windows not providing syslog. Please let me know if there is a better/cleaner/more LibreSSLy way of doing things like this.

I liked making sure of the already defined NO_SYSLOG which is used as part of crypto/compat/r_syslog.c hence why this was picked.

Sockets / Networking

We currently use the LWIP networking stack. My plan was to submit another PR with a compatibility shim for that. As a result, I don't know the status of building for the built-in FreeRTOS stack. It's my understanding it follows the standard socket API so might just work (TM)...

[botovq]

I made a first pass over your diff and it looks pretty good. Most of my comments are very nitpicky and stylistic. The main points:

• Please make the libressl_ prefixing completely straightforward, so we change things this using sed, as far as possible.
• The pthread API is special in that it returns an errno value, not -1 (there's also a bug in the windows shim).
• I am fine with using the NO_SYSLOG logic, but it needs fixing for WIN32 on the autotools level.

[botovq]

Suggested change

	xSemaphoreHandle x = mutex->handle;
	if (x) {
	if ( xSemaphoreGive(x) == pdTRUE ) {
	return 0;
	}
	else {
	return -1;
	}
	}
	return 0;
	if (mutex->handle == NULL)
	return 0;
	if (xSemaphoreGive(mutex->handle) == pdTRUE)
	return 0;
	return -1;

[projectgoav]

In mutex_lock we:

• Return -1 if the mutex handle is NULL, here we return 0. Should we be consistent here and return -1 as well?
• We compare != pdTRUE and final return is the happy path. Here, we compare == pdTRUE and the final return is a non-happy path. Should we be consistent and != pdTRUE with happy path the final return?

[botovq]

This seems fine if we fix autotools.

[botovq]

I think all return -1 should actually be an errno, such as EINVAL. This seems also incorrect in the windows pthread shim. I have not corrected that in my suggestions below.