Merge #19375: build: target Windows 7 when building libevent and fix ipv6 usage

eb6b73540d1ee7ff5a6874dd0e35f9b30b68e3b8 build: pass _WIN32_WINNT=0x0601 when building libevent for Windows (fanquake)
03e056edcd1a7f7197a29068c52fa33fce12f7d7 depends: Patch libevent build to fix IPv6 -rpcbind on Windows (Luke Dashjr)

Pull request description:

  TLDR: This poaches a commit from #18287 and adds one more to adjust the Windows version targeted when building libevent. These changes combined should fully fix ipv6 usage with the RPC server on Windows.

  ---

  Binding the RPC server to a ipv6 address does not currently work on Windows.
  We currently try and bind to `127.0.0.1` and `::1` [by default](https://github.com/bitcoin/bitcoin/blob/master/src/httpserver.cpp#L304).

  On Windows you'll see lines like this in debug.log:
  ```bash
  2020-06-24T01:49:04Z libevent: getaddrinfo: nodename nor servname provided, or not known
  2020-06-24T01:49:04Z Binding RPC on address ::1 port 8332 failed
  ```

  This issue was bought up in, and supposedly fixed by #18287, however the two people that tested it, both said that it didn't fix the problem. I think I now understand why that change alone is incomplete.

  Our call into libevent starts with [evhttp_bind_socket_with_handle()](https://github.com/bitcoin/bitcoin/blob/master/src/httpserver.cpp#L325):
  ```bash
  evhttp_bind_socket_with_handle()
  	bind_socket()
  		make_addrinfo()
  			evutil_getaddrinfo()
  				if #USE_NATIVE_GETADDRINFO
  					#ifndef AI_ADDRCONFIG
  						evutil_adjust_hints_for_addrconfig_()
  							evutil_check_interfaces()
  								evutil_check_ifaddrs()
  									evutil_found_ifaddr()
  										// miss identifies ipv6 as ipv4?
  					#endif
  					evutil_getaddrinfo_common_()
  ```

  The problem is falling into ["#ifndef AI_ADDRCONFIG"](https://github.com/libevent/libevent/blob/master/evutil.c#L1580):

  ```cpp
  #ifndef AI_ADDRCONFIG
  	/* Not every system has AI_ADDRCONFIG, so fake it. */
  	if (hints.ai_family == PF_UNSPEC &&
  	    (hints.ai_flags & EVUTIL_AI_ADDRCONFIG)) {
  		evutil_adjust_hints_for_addrconfig_(&hints);
  	}
  #endif
  ```

  When this occurs, hints end up being adjusted, and it seems that ipv6 addresses end up being mis-identified as ipv4?

  However this shouldn't happen, as these `AI_` definitions are available on Windows.
  The issue is that in evutil.c, `_WIN32_WINNT` [is set to `0x501`](https://github.com/libevent/libevent/blob/master/evutil.c#L45) (XP).

  This obviously predates Vista (`0x0600`), which is when the `AI_ADDRCONFIG` definition (and others) became [available](https://docs.microsoft.com/en-us/windows/win32/api/ws2def/ns-ws2def-addrinfoa).

  The change here will override libevents internal D_WIN32_WINNT defines. This should be ok, because it's only making "more" of the Windows API available. It's also aligned with what we do in our own configure, we pass [`D_WIN32_WINNT=0x0601`](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L610). We also now use linker flags to restrict our binary from running on a Windows version [earlier than Windows 7](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L621).

  The combined fixes can be tested by running:

  `bitcoind -rpcbind=::1 rpcallowip='0.0.0.0/0' -debug=http`

  and then querying it using:

  `bitcoin-cli -rpcconnect=::1 getblockchaininfo`

  TODO:
  - [x] Open an issue upstream. https://github.com/libevent/libevent/issues/1041

ACKs for top commit:
  laanwj:
    ACK eb6b73540d1ee7ff5a6874dd0e35f9b30b68e3b8

Tree-SHA512: e1e50f194911301981edaed0c216ed4efb9ebd4a1f9bc9b9f85bec7140b66c45c8666fd5db4aad359596559d4a08ab7c920e9d9736f3ecdbb841afc54e40586e

0 files changed, 0 insertions, 0 deletions