Tags added via api cleared on consul reload with enable_tag_overrides true

When filing a bug, please include the following headings if possible. Any example text in this template can be deleted.

#### Overview of the Issue

We use prepared queries to route requests to an online service that has a tag set to "active." In functionality its similar to the redis/sentinel example from the docs. We register services via files in a conf.d directory and then via the catalog api endpoint set the "active" tag on 1 service. The issue we are having is even with enable_tag_overrides: true, the tags set via the catalog api endpoint are cleared on a consul reload.

#### Reproduction Steps

Steps to reproduce this issue, eg:

1. Create a cluster of consul nodes running 1.7.2. Started with a --config-dir specified.
2. Register a service by rending a file similar to below to the config-dir:
```
{
"services": [{
"enable_tag_override": true,
"id": "app",
"name": "app",
"tags": [],
"address": "192.168.30.32",
"port": 7001,
"checks": [{
"http": "http://127.0.0.1:7001/health",
"interval": "5s",
"timeout": "4s"
}]
}]
}
```
3. Execute consul reload to load the new service
4. Run an http put to /v1/catalog/register with the following body
```
{
"ID": "d07ddf8c-5518-9368-e1cd-b5fcc90db2d6",
"Node": "nodeName",
"Address": "192.168.30.32",
"Datacenter": "dc2",
"Service": {
"ID": "app",
"Service": "app",
"Tags": [
"active"
],
"Address": "192.168.30.32",
"Port": 7001,
"EnableTagOverride": true
}
}
```
5. Do an http get on /v1/catalog/service/app and confirm the active tag is set.
6. Execute consul reload on nodeName, and perform the same http get again. The active tag will be gone.

### Consul info for both Client and Server

Client info

```
./consul info
agent:
check_monitors = 2
check_ttls = 0
checks = 3
services = 3
build:
prerelease =
revision = 9ea1a204
version = 1.7.2
consul:
acl = enabled
known_servers = 3
server = false
runtime:
arch = amd64
cpu_count = 6
goroutines = 72
max_procs = 6
os = linux
version = go1.13.7
serf_lan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 4017
failed = 0
health_score = 0
intent_queue = 0
left = 1
member_time = 18061
members = 153
query_queue = 0
query_time = 15
```

Server info

```
agent:
check_monitors = 1
check_ttls = 0
checks = 1
services = 1
build:
prerelease =
revision = 9ea1a204
version = 1.7.2
consul:
acl = enabled
bootstrap = false
known_datacenters = 2
leader = false
leader_addr = 192.168.30.134:8300
server = true
raft:
applied_index = 191343157
commit_index = 191343157
fsm_pending = 0
last_contact = 8.083712ms
last_log_index = 191343157
last_log_term = 2116
last_snapshot_index = 191337953
last_snapshot_term = 2115
latest_configuration = [{Suffrage:Voter ID:9b04206f-1f82-edd9-9b83-48d9e3c97b9e Address:192.168.30.133:8300} {Suffrage:Voter ID:4628c4e3-50a1-73f0-9e15-67c71d185a51 Address:192.168.30.132:8300} {Suffrage:Voter ID:d26e10dd-7f5b-c54a-d702-cc8e0e58fdf5 Address:192.168.30.134:8300}]
latest_configuration_index = 0
num_peers = 2
protocol_version = 3
protocol_version_max = 3
protocol_version_min = 0
snapshot_version_max = 1
snapshot_version_min = 0
state = Follower
term = 2116
runtime:
arch = amd64
cpu_count = 2
goroutines = 532
max_procs = 2
os = linux
version = go1.13.7
serf_lan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 4017
failed = 0
health_score = 0
intent_queue = 0
left = 1
member_time = 18061
members = 153
query_queue = 0
query_time = 15
serf_wan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 1
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 590
members = 6
query_queue = 0
query_time = 1
```

### Operating system and Environment details

OS, Architecture, and any other information you can provide about the environment.
>cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.8 (Maipo)

### Log Fragments

Include appropriate Client or Server log fragments. If the log is longer than a few dozen lines, please include the URL to the [gist](https://gist.github.com/) of the log instead of posting it in the issue. Use `-log-level=TRACE` on the client and server to capture the maximum log detail.

Start by reproducing the issue with a service registered from the config-dir, the catalog register API, and consul reload on version 1.7.2. Compare the catalog service response before and after reload; done means the API-added "active" tag remains when enable_tag_override is true.

Written by the indexing model from the issue text.