Feature/coap

DO NOT MERGE (WIP)
============

> This PR references issue  https://github.com/telefonicaid/fiware-orion/issues/283.

I present a few notes and issues that I've been collecting while developing this module, as they may be useful to understand it.
Dependencies
----
* cantcoap
    * Simple CoAP library (https://github.com/staropram/cantcoap).
    * Installation:
```
make
sudo cp cantcoap.h /usr/include
sudo cp dbg.h /usr/include
sudo cp nethelper.h /usr/include
sudo cp libcantcoap.a /usr/lib
```
* libcurl-devel
    * HTTP internal client.
* Boost
    * Threading and smart pointers.
    * Already using it.
* libcoap
    * Only for the coap-client for now.


Considerations about CoAP
-------------------------
> CoAP specification is not a draft anymore. It achieved the status of RFC as of June 2014. See http://tools.ietf.org/html/rfc7252.

* Currently body size is set to 1024 bytes, which is the maximum CoAP supports. It is known that many applications will use even smaller datagram sizes (in the order of 128 bytes total, including IP and UDP headers). **Multi-datagram** requests and responses are not implemented, but it is high priority.
* CoAP supports simple (but manual) retransmission and ACKed messages. The latter is implemented, the former is not, and to my understanding it's not very urgent to do so.
* Default port is 5683, which MUST be supported (for multicast service discovery purposes).
    * TODO: Make it configurable for the admin to change it.
* CoAP implements an **observer** mechanism that could play very well with the subscriber pattern in Orion (more research needed). For starts, it only supports ONCHANGE type events.

Wireshark
---------
* Versions of Wireshark that are installed by default in most distros today do not decode CoAP properly. This should now get better with the RFC status.
* I compiled and used the very latest version 1.12.0-rc, which still doesn't 100% support it, but it goes a long way nevertheless.
    * Once compiled, I found it useful to use this to pipe tcpdump into wireshark (since it did not want to run as root or give my user access to the interfaces):

```bash 
sudo tcpdump -s 0 -U -n -w - -i lo > ~/pipe
WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 ./wireshark -k -i ~/pipe
```
* Alternatively, you could just dump into a file and analyze later:

```bash
sudo tcpdump -w ~/out.pcap -i lo
WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 ./wireshark -r ~/out.pcap
```
Copper CoAP extension for Firefox
--
* Only recommended to do simple tests, not really useful other than that.
* Make sure you check the *Debug Control* option, or else it will not send any headers (Accept, Content-Format, ...).
* I did all my tests with a block size of 1024.

coap-client
--
coap-client is a curl-like CLI utility that comes bundled with the libcoap library. It is fairly easy to use:
```bash
coap-client -B 1 -b 1024 -A application/json coap://0.0.0.0/ngsi10/contextEntities/Room1
```
This is the one used for the harness tests.
Other issues
--
* **Notifications**: Orion should have a way to know whether to send a notification through its HTTP interface or the CoAP one. Possibilities:
    * The very same URL that will be notified contains the protocol to use.
    * I tell the broker specifically what to use (a new header in the subscription request? extension to the subscribeRequest message?).
    * Store in DB how the subscription was made and keep using that. Less flexible, but simpler.
    * Ideas?
* Due to CoAP inherent nature, it would make A LOT more sense to focus on JSON for request/response **encoding**.
    * TODO: The JSON contained in a response can and should be stripped of all unnecesary characters such as newlines and spaces.
* There are other protocols that are for sure more suited to this kind of application (for example, ASN.1). It is a small benefit for such a daunting task, though. Scrapped.


Fixed in aefaecf