#9 Add request and response functionality for network requests and the corresponding responses

A connection class seems also necessary.

This problem needs more thinking before programming can continue...

Concept 1:

• The Request class contains just the “metadata” like host, path, protocol method and other header fields.
• The MNENetProtocolhandler (MNENPH) gets a Request object to produce a Connection identifier out of it.
• Additional data (the request body) is sent to the MNENPH together with the connection-ID as vector.
• The MNENPH calls a closure in case the full respone header has been read. The closure gets a ResponseHeader object.
• The MNENPH calls a closure in case a specified amount of data is read from the response. The data is passed as vector<uint8_t>.

Concept 2:

• The Request class contains just t he “metadata” like host, path, protocol method and other header fields. It also contains an ID field that is unique for all requests made during program execution.
• The MNENetProtocolHandler (MNENPH) gets a Request object, together with two other objects, where one of those implements ResponseHeaderHandler and the other one ResposeDataHandler.
• The MNENPH can receive additional data (request bodies) that must specify a Request-ID in addition to the body data.
• When the MNENPH has read the complete header, it calls a method on the ResponseHeaderHandler object that processes the header.
• When the MNENPH has read a specified (or sufficient) amount of data, it calls a method on the ResponseDataHandler object that processes the data.
• In both cases where the MNENPH calls the handlers, it also passes the Request-ID so that the handlers can distinguish the responses for different requests.

Concept 2 seems more reasonable and will be implemented.

Concept 3:

• MNENetProtocolHandler will be removed.
• A new Request class will be created as base class for protocol-specific specialisations. The base class will allow clients to send “raw” requests (no header etc.).
• Request class instances will be linked directly to a NetworkHandler instance, so that there is no additional layer when sending/receiving data.
• When calling Request::send() for a Request object, it creates the request header and passes the “raw” data (header + body) to the NetworkHandler.
• The Request class will have a mutex and two semaphores: The first represents the “response header ready” status, the second represents the “response data available” status. Both get locked when the request is made. The first semaphore becomes unlocked once the response header is completely read. The second one becomes unlocked when a data block is available. If that data is passed on, it becomes locked again until the end of the response is read. The mutex makes sure that either a data block is read or written and prevents that both happens at the same time.
• The NetworkHandler starts a new thread for each request before actually sending it. This way, multiple requests can be started at the same time.
• The NetworkHandler thread for a Request object passes data to the Request object in case it hasn’t set the “aborted” flag that specifies that the request has been aborted and no more recceived data will be processed.
• In case of an aborted request, the NetworkHandler will end the thread that receives data.

Concept 3 seems even more reasonable so that steps towards implementing it will be made.

(Content from Concept 3 has been copied into the issue text)

Addendum to concept 3:

Add a ResponseHandler interface and make the Request class an implementation of it. Otherwise, there would be a circular include: Request requires NetworkHandler, NetworkHandler requires Request.

21190130ff belongs here.