Log message:
Remove nettle3, used for updating security/nettle

Log message:
Update to 3.1.1:

NEWS for the Nettle 3.1.1 release

	This release fixes a couple of non-critical bugs.

	Bug fixes:

	* By accident, nettle-3.1 disabled the assembly code for the
	  secp_224r1 and secp_521r1 elliptic curves on all x86_64
	  configurations, making signature operations on those curves
	  10%-30% slower. This code is now re-enabled.

	* The x86_64 assembly implementation of gcm hashing has been
          fixed to work with the Sun/Oracle assembler.

	The shared library names are libnettle.so.6.1 and
	libhogweed.so.4.1, with sonames still libnettle.so.6 and
	libhogweed.so.4. It is intended to be fully binary compatible
	with nettle-3.1.

NEWS for the Nettle 3.1 release

	This release adds a couple of new features.

	The library is mostly source-level compatible with nettle-3.0.
	It is however not binary compatible, due to the introduction
	of versioned symbols, and extensions to the base64 context
	structs. The shared library names are libnettle.so.6.0 and
	libhogweed.so.4.0, with sonames libnettle.so.6 and
	libhogweed.so.4.

	Bug fixes:

	* Fixed a missing include of <limits.h>, which made the
	  camellia implementation fail on all 64-bit non-x86
	  platforms.

	* Eliminate out-of-bounds reads in the C implementation of
	  memxor (related to valgrind's --partial-loads-ok flag).

	Interface changes:

	* Declarations of many internal functions are moved from ecc.h
	  to ecc-internal.h. The functions are undocumented, and
	  luckily they're apparently also unused by applications, so I
	  don't expect any problems from this change.

	New features:

	* Support for curve25519 and for EdDSA25519 signatures.

	* Support for "fat builds" on x86_64 and arm, where the
	  implementation of certain functions is selected at run-time
	  depending on available cpu features. Configure with
	  --enable-fat to try this out. If it turns out to work well
	  enough, it will likely be enabled by default in later
	  releases.

	* Support for building the hogweed library (public key
	  support) using "mini-gmp", a small but slower implementation
	  of a subset of the GMP interfaces. Note that builds using
	  mini-gmp are *not* binary compatible with regular builds,
	  and more likely to leak side-channel information.

	  One intended use-case is for small embedded applications
	  which need to verify digital signatures.

	* The shared libraries are now built with versioned symbols.
	  Should reduce problems in case a program links explicitly to
	  nettle and/or hogweed, and to gnutls, and the program and
	  gnutls expect different versions.

	* Support for "URL-safe" base64 encoding and decoding, as
          specified in RFC 4648. Contributed by Amos Jeffries.

	Optimizations:

	* New x86_64 implementation of AES, using the "aesni"
	  instructions. Autodetected in fat builds. In non-fat builds,
	  it has to be enabled explicitly with --enable-x86-aesni.

	Build system:

	* Use the same object files for both static and shared
	  libraries. This eliminates the *.po object files which were
	  confusing to some tools (as well as humans). Like before,
	  PIC code is used by default; to build a non-pic static
	  library, configure with --disable-pic --disable-shared.

	Miscellaneous:

	* Made type-checking hack in CBC_ENCRYPT and similar macros
	  stricter, to generate warnings if they are used with
	  functions which have a length argument smaller than size_t.

Log message:
Import nettle-3.0 as wip/nettle3:
Breaks gnutls-3.2.15, wait for better releases.

Nettle is a cryptographic library that is designed to fit easily in more
or less any context: In crypto toolkits for object-oriented languages
(C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in
kernel space. In most contexts, you need more than the basic
cryptographic algorithms, you also need some way to keep track of available
algorithms, their properties and variants. You often have some algorithm
selection process, often dictated by a protocol you want to implement.

And as the requirements of applications differ in subtle and not so
subtle ways, an API that fits one application well can be a pain to use
in a different context. And that is why there are so many different
cryptographic libraries around.

Nettle tries to avoid this problem by doing one thing, the low-level
crypto stuff, and providing a simple but general interface to it.
In particular, Nettle doesn't do algorithm selection. It doesn't do
memory allocation. It doesn't do any I/O.

The idea is that one can build several application and context specific
interfaces on top of Nettle, and share the code, test cases, benchmarks,
documentation, etc. Examples are the Nettle module for the Pike
language, and LSH, which both use an object-oriented abstraction on top
of the library.