External profiles seem to be broken

Nobody has claimed this yet.

## Bug Report

### What is the issue?
External profile support seems to be broken (or just finicky), per debugging comments from @adleong

### How can it be reproduced?
Create a service profile like:
```yaml
---
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: myapp.NAMESPACE.svc.cluster.local
namespace: NAMESPACE
spec:
routes:
- condition:
method: GET
pathRegex: /api/foo/.*
name: GET /foo
- condition:
method: GET
pathRegex: /api/bar/.*
name: GET /bar
```
Add annotation on `myapp` deployment:
```
config.linkerd.io/enable-external-profiles: "true"
```
Access the service via an external URL, i.e. `blah.example.com/api/foo`

### Logs, error output, etc

The `authority` of the requests is `blah.example.com`, and those requests don't have any route assigned. Internal requests (from within the cluster) to `myapp` work and show in routes as expected.

#### `linkerd check` output

All green checks

### Environment

- Kubernetes Version: 1.13
- Cluster Environment: EKS
- Host OS: EKS
- Linkerd version: 2.5

### Possible solution
Tried setting service profile name to `blah.example.com` as requested, but that doesn't seem to make a difference for metrics, and doesn't show up in `/namespaces/NAMESPACE/deployments/myapp` on the dashboard.

### Additional context

https://linkerd.slack.com/archives/C89RTCWJF/p1567199653273600 has a bunch of debugging steps and context

No source files or tests are named. Start by reproducing the external-profile example with the stated Kubernetes and Linkerd versions, then inspect how the external authority `blah.example.com` is matched to the service profile and how routes appear in the dashboard endpoint. Done means external requests receive the expected GET /foo and GET /bar routes and the profile appears in the deployment dashboard.

Written by the indexing model from the issue text.