Major rewrite of the socket processing routines

[DL6ER]

By submitting this pull request, I confirm the following:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10

---

Major rewrite of the socket processing routines of FTL's Telnet-like API.

Before, we launched a new thread for each incoming connection (more than 40 threads concurrent were never allowed) to handle incoming connections independent from another and serve content concurrently. However, this could potentially be used to DoS FTL by opening and closing telnet sessions in very quick succession.
The new behavior is to, instead, launch five (compile-time setting) threads per type (independent for telnet over IPv4, IPv6, and Unix socket communication = 15 threads in total). Each of them accepts incoming connections in a FIFO manner (they always pick the first connection in the waiting connection queue). If too many requests are sent to FTL at once, they will simply be queued by the system until FTL is ready to accept them.

This is meant as a bugfix related to pi-hole/PADD#252,

[yubiuser]

Why is istelnet missing in /api/reques.c for all messages >cacheinfo up to >interfaces

[DL6ER]

The Unix socket interface was introduced after the Telnet was already present. It was supposed to become the interface between FTL and the at that time drafted (and now abandoned) HTTP API written in another language. As the Telnet-like replying using ASCII-encoded numbers is pretty inefficient for machine-machine communication, we implemented MessagePack instead (#75) which allows for more efficient streaming.

After it got clear that the HTTP API isn't going to make it, we abandoned the development of the Unix socket part and new API endpoints did not get a different output than "ordinary" Telnet requests (this is the answer to your qeustion). We could (and maybe should) have removed the Unix socket sometime in between as I'm not sure anyone on this planet is actually using it. However, we still have it. All this code is removed for new/http where we will only provide a standardized REST interface instead.

[yubiuser]

We could (and maybe should) have removed the Unix socket sometime in between as I'm not sure anyone on this planet is actually using it.

Maybe this PR is a good place to remove all fragments of the Unix socket?

[dschaper]

My self-assignment isn't a blocker for merge.