Assign multiple servers to a capability

[rimashah25]

Closes: #6033

---

Which Traffic Control components are affected by this PR?

• Documentation
• Traffic Ops
• Traffic Portal

What is the best way to verify this PR?

Using API test the new route with a list of servers for a given server capability

Success Assignment
curl -X POST -k -H "Accept: application/json" --cookie "mojolicious=" --data @mspc.json https://localhost:port/api/4.1/multiple_servers_capabilities/

{
	"alerts": [{
		"text": "Multiple Servers assigned to a capability",
		"level": "success"
	}],
	"response": {
		"serverCapabilities": ["eas"],
		"serverIds": [3, 2]
	}
}

Incorrect route
curl -X POST -k -H "Accept: application/json" --cookie "mojolicious==" --data @mspc.json https://localhost:port/api/4.0/multiple_servers_capabilities

{
	"alerts": [{
		"text": "The requested path '/api/4.0/multiple_servers_capabilities' does not exist.",
		"level": "error"
	}]
}

Using TP

1. Once you create a server capability, click on created server capability (eg: disk), and then click on Manage Servers (changed the name from View Servers)
2. To assign multiple servers to a capability, click on image,
   
3. A new dialog window listing all servers (and the one assigned to the existing server as checked) should open up, like this:

5. You can chose from the list and click submit and then see it update on the server/<server_name>/capabilties table.

If this is a bugfix, which Traffic Control versions contained the bug?

PR submission checklist

• This PR has tests
• This PR has documentation
• This PR has a CHANGELOG.md entry
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[ocket8888]

I know this would probably be a large change at this point, but why not just augment the existing /multiple_server_capabilities route to accept an array of both server IDs and Capability names instead of making a whole new endpoint?

[rimashah25]

Sorry just seeing this, where are those checks? I usually do a POST followed by a GET to make sure whether or not the operation actually went through to the database or not.

The way new integration tests are written, one doesn't need do that.

[srijeet0406]

Manual testing looks good. I'm just mentioning this here so that we have a comment to refer to in the future. If you hit the POST endpoint with multiple server IDs and one server capability, but the pageType is set to server, it will still just associate the one server capability to just the FIRST server in that list (since the pageType is server).
Similarly, if you hit the same endpoint with multiple server capabilities and just one server ID, but with the pageType set to sc, it will assign ONLY THE FIRST server capability to the server.

The above is only applicable for users hitting the API directly, because TP adds these checks before passing in the request.

Otherwise, all many to many assignments fail as expected.
Any pageType other than server and sc fails as expected.
A blank pageType fails as expected.

I'll merge it once GHA tasks pass.