build: undo Werror=unused-variable #17533

Partial revert of #17486.

First we need to avoid tripping this check whenever a dependency introduces an unused variable.

#14920 tackles this

ACK f327e82b0266b9ac455c8b82434528d670eee6a8

What is actually failing with -Werror=unused-variable? I can build depends and configure master (76e777df83db4fc14d5cf96c67ceaa554a016a3a) with --enable-werror and I'm not seeing any issues.

@fanquake It depends on what libraries your system comes with. E.g. it fails when your system ships a "broken" boost: https://travis-ci.org/bitcoin/bitcoin/jobs/613924094#L10291

@MarcoFalke Right, but that failure isn't using system Boost, it's building Boost from depends. So are we assuming that builds for people using master and system libraries are also currently failing when using --enable-werror? It would be good to get some examples.

The problem this PR is "fixing", which is unclear from the description, is that 15382 introduces a dependency on Boost Process, and in Boost 1.70.0 (used in depends) there is an unused variable in the process module boost/process/detail/posix/wait_group.hpp:140:13: error: unused variable 'ret_sig', which is supposedly fixed in Boost 1.71.0.

I just want to be clear why this is being reverted, because when it was introduced in #17486, depends and system libs seemed to be building fine under --enable-werror (and seemingly still are). However now we're going to revert part of the change because a PR with 1 (outdated) ACK, that introduces a new Boost dependency, is failing to build under --enable-werror.

I'd presume that this also fails when a system library is broken, but I haven't checked.

In my experience it only failed on a PR that started using a previously unused part of Boost #15382. We could of course leave this PR open until it actually breaks something on Travis. Maybe #14920 is merged before that's needed.

Right, but that failure isn't using system Boost, it's building Boost from depends.

I can also produce that failure with system Boost in that PR, but only 1.70; it was fixed in 1.71

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

Going to close this. If this change is required by a PR (#15382), it should be included in that PR (looks like it is), rather than applied to the build system in advance. Also see my comment above; #17533 (comment). #15382 could also be taking other approaches, like at least patching boost process in depends, rather than reverting a good, project-wide build system change because a single optional function causes issues.