Fixes the inability to clone ds assignments across servers when 1+ ds is assigned a topology

[mitchell852]

What does this PR (Pull Request) do?

With the introduction of topologies, it no longer makes sense to assign caches directly to a delivery service if that ds utilizes a topology. Therefore, a constraint was added to the following api in #4702 to prevent delivery services from being assigned directly to a server if that delivery service utilizes a topology:

POST api/version/servers/{server-id}/deliveryservices

However, a common practice when provisioning new caches is to clone the ds assignments (or bulk assign) from an existing cache to the newly provisioned cache using the aforementioned endpoint. However, due to the new constraint added in #4702, this activity will inevitably fail as more delivery services start to use topologies but were never directly unassigned from the servers in which they were previously assigned. Confused yet?

Anyhow, removing this constraint will ease the transition from delivery services that utilize a topology and other delivery services that choose to assign servers directly.

In addition, when assigning ds's directly to a server, it makes no sense to directly assign topology-based ds's to a server, therefore, those ds's have been disabled (or are unselectable) in TP.

TLDR; this PR allows bulk assignment of ds's to a server even if one of those ds's utilizes a topology but prevents individual assignment of a ds with a topology to a server (in TP). Because bulk assignment is part of the new server provisioning playbook and cannot be broken.

• This PR fixes TP: only delivery services not assigned to a topology can be assigned directly to a server #4860

Which Traffic Control components are affected by this PR?

• Traffic Ops

What is the best way to verify this PR?

• Run the API and UI tests and/or
• curl -X POST --data '[dsId]' https://trafficops.domain.com/api/3.x/servers/{server-id}/deliveryservices?replace=true where dsId is the id of a delivery service that utilizes a topology. The POST should succeed.
• in TP:
  -- edit a delivery service to use a topology. create a topology first if you have to.
  -- view the delivery services of a server in the same cdn - https://tp.domain.com/#!/servers/{server-id}/delivery-services
  -- click on the Link Delivery Services to Server button
  -- notice that the delivery service with the topology assigned cannot be selected for direct assignment to the server.

If this is a bug fix, what versions of Traffic Control are affected?

• master

The following criteria are ALL met by this PR

• This PR includes tests OR I have explained why tests are unnecessary
• This PR does NOT include documentation
• This PR does NOT include an update to CHANGELOG.md as the bug was introduced between releases
• This PR includes any and all required license headers
• This PR ensures that database migration sequence is correct OR this PR does not include a database migration
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[shamrickus]

LGTM

• TO unit/integration tests pass
• TP integration tests pass
• No go fmt issues
• Able to assign Servers to DS with Topologies
• TP disables assigning single topology based ds to a server