Partitioned _all_docs endpoint with non-partitioned docId answers with not-properly-formatted HTTP response

[NOTE]: # ( ^^ Provide a general summary of the issue in the title above. ^^ )

## Description

[NOTE]: # ( Describe the problem you're encountering. )
[TIP]: # ( Do NOT give us access or passwords to your actual CouchDB! )
This problem occurs only on CouchDB.
Can be reproduced with PostMan and `ibm-cloudant` js and java package.
With `POST {db}/_partition/{partition}/_all_docs` endpoint if the body contains a non partitioned key e.g: "invalidKey" then the server (CouchDB) responds intermittently `400 Bad Request`.

## Steps to Reproduce
1. Create a partitioned database
2. Send the following request:
```
POST {db}/_partition/{partition}/_all_docs
{
"keys": [
"doc12"
]
}
```
The PostMan will respond with no result code and the following error message:
```
Could not get any response
There was an error connecting to {couchdb_url}/{db}/_partition/{partition}/_all_docs.
Why this might have happened:
The server couldn't send a response:
Ensure that the backend is working properly
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
Proxy configured incorrectly
Ensure that proxy is configured correctly in Settings > Proxy
Request timeout:
Change request timeout in Settings > General
```

The JS package will response with:
```
400 "HPE_INVALID_CONSTANT"
body: "Response not received - no connection was made to the service."
message: "Parse Error: Expected HTTP/"
stack: "Error: Parse Error: Expected HTTP/
at RequestWrapper.formatError (../node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:208:21)
at ../node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:196:25
at processTicksAndRejections (internal/process/task_queues.js:85:5)"
```

The Java responds with:
```
Caused by: java.net.ProtocolException: Unexpected status line: 2c
at okhttp3.internal.http.StatusLine.parse(StatusLine.java:69)
```

[NOTE]: # ( Include commands to reproduce, if possible. curl is preferred. )
If you make this command with curl command with verbose option:
```
curl --request POST {couchdb_url}/{db}/_partition/{partition}/_all_docs' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic {token}' \
--data-raw '{"keys": ["invalidKey"]}' -v
```
Then the curl response sometimes includes the following line:
`* Excess found in a non pipelined read: excess = 58, size = 73, maxdownload = 73, bytecount = 0`

## Expected Behaviour
The PostMan, JS and Java package should receive a well-formatted HTTP response.

[NOTE]: # ( Tell us what you expected to happen. )

## Your Environment

[TIP]: # ( Include as many relevant details about your environment as possible. )
[TIP]: # ( You can paste the output of curl http://YOUR-COUCHDB:5984/ here. )

* CouchDB version used: "3.0.0-6d432a9"
* Browser name and version: PostMan 7.15.0
* Operating system and version: MacOS Catalina 10.15.2

## Additional Context

[TIP]: # ( Add any other context about the problem here. )

Start by reproducing the partitioned database POST to the _partition/{partition}/_all_docs endpoint with a non-partitioned key, using the curl command and verbose output from the issue. Trace how CouchDB handles this request and verify that invalid keys produce a complete, well-formed HTTP response rather than a malformed status line or excess bytes.

Written by the indexing model from the issue text.