Fix fileringbuffer locking up on read()

From time to time, most often seen during LiveTV, FileRingBuffer::safe_read() would lock and not return for a long time (on my system, it would block in excess of 20s).
Upon investigation, the issue occurs while reading a file currently being written to, if a call to read() encountered EOF, returned early and a following call to read() was made, before another write. Under those conditions, read() wouldn't return for a long time, causing the backend to abort the read and dropping the frontend connection.

So instead we now check the size of the current file via a call to POSIX fstat and never try to read beyond the EOF position.
If the file being read isn't a regular, or fstat returned an error, the old behaviour is used: read until we get as much data as we asked.

Surprisingly, this has fixed most of the issues I've been having for years with liveTV:
- Stuttering or temporary free when close to the live
- Freeze at program transition.

Add debugging information while in file mode

Fixes #12045

(cherry picked from commit 20f7cd2858e79385ceec07b2c19c7e4f84714e18)
Have backend advertise which files are currently being written to

It is necessary in some playback scenarios to know if a file being read is currently being written to. This is useful in determining when encountering EOF if we should wait for more data or abort the read.

MythCoreContext will now keep track of files as they are being opened for writing
Connected frontends will receive the information via the event socket in the form of a BACKEND_MESSAGE event.

The myth protocol is extended with two new BACKEND_MESSAGE events:
FILE_WRITTEN: Sent when a file is opened in write mode, and when the file is being written to (at most every 10s)
FILE_CLOSED: Sent when the file opened in write mode is closed.

The myth protocol version doesn’t have to be increased as frontends will make use of it only if available and the changes are backward compatible with exiting myth protocol.

(cherry picked from commit fafc658597b547e2f0173032515e9790170ebcbe)

Conflicts:
	mythtv/libs/libmythbase/threadedfilewriter.cpp
Prevent playback to exit early should backend's writes be delayed

Typical scenario is when watching on-going recordings and being very close to real time TV: should the backend take more than 360ms between two writes, the reader would treat it as an EOF and abort the read.

When encountering EOF, we now check if the file is being written to in parallel and if so wait.

We can also remove all EOF retries in FileRingBuffer::safe_read() as we definitely know now if we did reach EOF (as we check against the file size).
This allows for almost instantaneous program transition in live TV.

(cherry picked from commit 443b624ebcc8ea56026cb49ca833edc7d73832c1)
Fix typo

CR got deleted for some reason

(cherry picked from commit 534394068373c52fd712d653e5fea725c564a673)
Allow seeking within the entire liveTV chain of recordings.

Seeking across liveTV was fundamentally broken. You could only seek within the current recordings or go to the beginning of the next one or 15s to the end of the previous one.
This changes correct this behaviour. It is now possible to seek across the entire live TV session. We ensure however that we do not seek further than 15s from the end of a recordings (3s if reaching end of live program).

Fixes #12076

(cherry picked from commit 11daeaadc52214605e204cdfe6f7c001c9c1cc9b)
Never attempt to read more than in 512kB blocks

Recalculate the threshold and read block size when we've encountered EOF several times in a row.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428

(cherry picked from commit 1cfdfa3f56876eb20170f33e9592b5c7ffd05064)
Bump API binary number following round of changes in ringbuffers
Change verbosity for some network messages
(cherry picked from commit e6245ca330bc7dcc4d358819a299b28f02f5b5a5)