Fixes #5246

This PR updates the destination to report an error when `Get`
is called for IP Queries. As the issue mentions, The proxies
are not using this API anymore and it helps to simplify and
remove unecessary logic.

This change is aimed for `stable-2.11`, and depends on
linkerd/linkerd2-proxy#972

Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>

…972)

Depends on #971

Currently, the proxy should only perform `Destination.Get` resolutions
for logical (named) addresses provided by `Destination.GetProfile`
lookups, and never for IP addresses. However, this is not *guaranteed*;
as the destination resolver still accepts a `LookupAddr` type which may
be either a logical named address *or* an IP address.

In order to remove support for IP lookups from the control plane's
`Destination.Get` implementation, we should ensure that the proxy will
*never* attempt to resolve an IP (see linkerd/linkerd2#5246). Now that
the `Logical` target type and the logical stacks are only constructed
when a profile is resolved (as of PR #963), we can now change the proxy
to ensure statically that this never happens.

This branch makes the following changes:

* Currently (as of #963), the `Logical` target type has an
  `Option<LogicalAddr>`. We attempt to unwrap the `Option<Receiver>`
  returned by a profile lookup, and build a logical stack when there is
  a profile. The `Logical` target is with `Option<LogicalAddr>` from
  that profile.

  However, this is not actually the ideal behavior: ideally, we would
  only contruct the logical stack when there is a resolved profile *and*
  the profile includes a logical address. Therefore, this branch changes
  the `push_unwrap_logical` function added in #963 to use a custom
  filter predicate that only constructs the `Logical` target when the
  profile resolution is `Some` _and_ the profile's `addr` field is
  `Some`. Now, `Logical` targets are only built when there is a known
  logical address.

* The `Destination.Get` resolver requires a target type that implements
  `Param<ConcreteAddr>`. Currently, a `ConcreteAddr` is a newtype around
  `Addr`, which may be either a named address or an IP address. This
  branch changes `ConcreteAddr` to a newtype around `NameAddr`. This
  means that the resolver now ensures `Destination.Get` queries are only
  performed for named addresses at the type level.

* Similarly, the `Target` type in `linkerd-service-profiles` is changed
  to store a `NameAddr` rather than an `Addr`.

* Several of the outbound stack tests now test invalid behavior that
  should no longer happen --- building a logical stack and calling it
  with a target that doesn't include a logical address. I rewrote these
  tests so that the tests without logical addresses don't build a
  logical stack, and added a new test for calling the logical stack
  with a logical address. In the process, I did some cleanup and
  refactoring in the outbound TCP stack tests.

* Finally, while debugging test failures, I noticed that the
  `fmt::Debug` output for some of the target types that include
  `NameAddr`s was a little unnecesarily verbose. I added new custom
  `Debug` impls that should make these a bit more concise.

This is the proxy component of linkerd/linkerd2#5246.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

* destination: Remove support for IP Queries in `Get` API

Fixes #5246

This PR updates the destination to report an error when `Get`
is called for IP Queries. As the issue mentions, The proxies
are not using this API anymore and it helps to simplify and
remove unnecessary logic.

This removes the relevant `IPWatcher` logic, along with
unit tests

Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>