Networking - `userland-proxy` could better clarify impact

The option was originally introduced in May 2015 with docs at docs/sources/articles/networking.md

• Relocated to docs/userguide/networking/default_network/binding.md via direct commit in Nov 2015.
• Removed in Feb 2018 with lots of other network content.

There is not much history on those changes to derive information on if this was intentional. Considering the size and intent of the two changes, it was likely accidental and difficult for any review to catch without investing significant time to be thorough.

• The first part of the referenced docs (that the original review said would not be needed), was not dropped for the ~3 years it was present in the docs for.
  • This was resolved in May 2015 and I briefly documented why ports are bound now regardless of userland-proxy setting.
  • I am not sure if this will remain the case with future developments, like the discussion of alternative port mappers.
• The remaining seemed relevant technical information to explain better what disabling the setting did:

  The --userland-proxy parameter, true by default, provides a userland implementation for inter-container and outside-to-container communication.
  When disabled, Docker uses both an additional MASQUERADE iptable rule and the net.ipv4.route_localnet kernel parameter which allow the host machine to connect to a local container exposed port through the commonly used loopback address: this alternative is preferred for performance reasons.

This is relevant information AFAIK. Along with the route_localnet kernel change. You can query 127.0.0.1, but not the IPv6 equivalent [::1] (which has no equivalent route_localnet). As the default binding 0.0.0.0 also includes IPv6 interfaces, this behaviour from userland-proxy: false is not obvious to track down. Works fine with userland-proxy: true.