DS SSL keys routes return empty 'response' objects on error

[ocket8888]

I'm submitting a ...

• bug report
• improvement request (usability, performance, tech debt, etc.)

(not sure which this would be considered)

Traffic Control components affected ...

• Traffic Ops

Current behavior:

When Traffic Vault has no keys for a Delivery Service but its keys are requested via /deliveryservices/xmlid/{{XMLID}}/sslkeys or /deliveryservices/hostname/{{hostname}}/sslkeys, Traffic Ops responds with a 200 OK response with a payload similar to:

{
	"alerts": [{
		"level": "info",
		"text": "No objects for MyXMLID"
	}],
	"response": {}
}

Expected / new behavior:

#3534 will change the response code to a more appropriate 404 Not Found and changes the Alert Level to error (I'm pretty sure), but doesn't change the response structure for backward compatibility reasons. For consistency, the response body should contain only the alerts key, because that's what everything else does.

Minimal reproduction of the problem with instructions:

Request SSL keys for a Delivery Service that has no SSL Keys stored in Traffic Vault using a GET request to either /deliveryservices/xmlid/{{XMLID}}/sslkeys or /deliveryservices/hostname/{{hostname}}/sslkeys.

[ocket8888]

This is actually different now. Now, if there are no keys for a DS, it returns some "default" key that doesn't actually exist and has some invalid fields, like:

{
	"response": {
		"key": "",
		"version": 0,
		"certificate": {
			"crt": "",
			"key": "",
			"csr": ""
		},
		"expiration": "0001-01-01T00:00:00Z"
	}
}

which is even worse, in my opinion