Kovri: remove i2pd's endian, replace with ByteStream + Boost.Endian

[anonimal]

---

By submitting this pull-request, I confirm the following:

• I have read and understood the contributor guide in kovri-docs.
• 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 that this pull-request may be closed by the will of the maintainer.
• I give this submission freely under the BSD 3-clause license.

---

Resolves #772. References #140. Referencing #511 #643 among others (see the TODOs).

[anonimal]

Live tests and unit-tests pass on BE and LE machines (tested on Linux/FreeBSD/Windows).

[anonimal]

OpenBSD and OS X apparently want to /usr/local/include/boost/endian/conversion.hpp:298:12: error: call to 'endian_reverse' is ambiguous. Resolve before merging.

[coneiric]

Great changes.

From what I've found so far, it looks like the ambiguous call error may be coming from the templated Read and Write functions.

There are multiple endian_reverse overloads for uintNN_t, which gets called by boost::endian::native_to_big_inplace() on little-endian machines.

Not sure what the right solution would be.

Maybe replacing:

if (native_to_big)
  boost::endian::native_to_big_inplace(data);

with

if (native_to_big)
  boost::endian::native_to_big_inplace(std::static_cast<decltype(data)>(data));

Then perhaps doing something similar for Read(), and other places where the boost::endian::{native_to_big*,big_to_native*} is passed a templated param?

[anonimal]

Not sure what the right solution would be.

The build failures exposed pre-existing kovri type issues. I've fixed those issues and now the build is resolved (casting is not the way to resolve the issue).

[anonimal]

Note: OSX router.info looks good, as expected, but Linux is producing a bad router.info (introduced before aforementioned patch in previous comment). Hold on merging until I resolve the issue.

[anonimal]

Resolved. Also amended // TODO(anonimal): there is no spec-defined size limit, but we need 2 bytes... when writing RI options.