Replace univalue subtree with proper dependency on external UniValue

[luke-jr]

This is not consensus-critical code, so really had no excuse to be subtree'd in the first place.

[luke-jr]

Actually, this loses a bugfix, so @jgarzik needs to release UniValue 1.0.2 to make this sane...

[luke-jr]

Also, I believe the Travis failure crash is unrelated to this PR, and a bug in UniValue (or Core) that we need to fix independently of this - but I can't reproduce it... :/

[jonasschnelli]

I think we should use the bitcoin/univalue.git repository to allow multiple people to maintain the repository (the subtree is also pointing to bitcoin/univalue.git).

[luke-jr]

AFAIK that's just a mirror of @jgarzik 's upstream? Note he could very well add additional maintainers to his upstream repo as well, if he wants.

[jonasschnelli]

Hmm.. not sure about that.
If I'm right, this would mean, in order to compile bitcoin-core, users need to checkout the univalue git repository and compile univalue by themselves unless there is broad support over package managers (apt-get, etc.)?

IMO we should use subtrees for dependencies that are not available over common package managers (bdb4.8 might be an exception because a) not really necessary [--with-incompatible-bdb] and b) wallet only).

[laanwj]

NACK. Univalue is a nice and small library, and it's useful to have it included.. This makes it much easier for people that want to build.

I'd be OK with the option to use an external univalue, but don't remove the internal one.

[luke-jr]

@laanwj Is it really so much harder to run:

make -C depends univalue

[MarcoFalke]

make -C depends univalue

You'd have to update doc/build*

[luke-jr]

Apparently the depends system can't actually be used in the way I expected.

While I still think this is the correct way to go, I'll start with making it an option for now... in #7349