Transit secret engine LIST /keys responds with 404 instead of empty list

[dnault]

When there are no keys, a LIST request to the /transit/keys HTTP endpoint gets a 404 response. Instead it should return a 200 response with an empty list of keys.

To Reproduce
Delete all the keys managed by transit. Then run:

curl -v -X LIST -H "X-Vault-Token: myAuthToken" localhost:8200/v1/transit/keys`

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8200 (#0)
> LIST /v1/transit/keys HTTP/1.1
> Host: localhost:8200
> User-Agent: curl/7.64.1
> Accept: */*
> X-Vault-Token: myroot
> 
< HTTP/1.1 404 Not Found
< Cache-Control: no-store
< Content-Type: application/json
< Date: Fri, 24 Apr 2020 00:57:27 GMT
< Content-Length: 14
< 
{"errors":[]}
* Connection #0 to host localhost left intact
* Closing connection 0```

Notice the HTTP/1.1 404 Not Found.

Expected behavior
Expected a 200 response with the normal response structure and an empty key list, something like:

{"request_id":"dca6eb2b-dcab-9b6f-94f2-0b193609c0ce","lease_id":"","renewable":false,"lease_duration":0,"data":{"keys":[]},"wrap_info":null,"warnings":null,"auth":null}

Environment:

• Vault Server Version (retrieve with vault status): 1.4.0
• Vault CLI Version (retrieve with vault version): n/a
• Server Operating System/Architecture: official docker image

[cipherboy]

@dnault This behavior is consistent across various APIs in Vault:

• transit/keys
• pki/roles
• pki/issuers
• pki/keys
• ssh/roles

and probably many others. Changing this behavior now is almost certainly a breaking change for many (200 implies non-empty response list). As such, I don't think we'll be addressing this issue. See the original rationale in #1365.