Fix perfstandbyok logic

[jefferai]

From an employee:

Currently, if you want a load balancer to load balance requests to performance standby servers in a Vault cluster, you have to set the health check to use /v1/sys/health?perfstandbyok=true&standbyok=true, using both the perfstandbyok and the standbyok parameters. If you only use the perfstandbyok=true, the perfstandbyok response code of 473 is changed to the standby response of 429. (You can see this with `curl -v $VAULT_ADDRESS/v1/sys/health?perfstandbyok=true calls.)

In my view, this is a bug which contradicts what this doc says: https://www.vaultproject.io/api/system/health.html#perfstandbyok "Specifies if being a performance standby should still return the active status code instead of the performance standby status code. This is useful when Vault is behind a non-configurable load balance that just wants a 200-level response."

This is because of the way the switch works in this code: https://github.com/hashicorp/vault/blob/master/http/sys_health.go#L140-L153

If you only set perfstandbyok=true, the case statement on line 149 is not matched but the one on line 151 is and that explains why the 473 perftstandby code is changed to the standby code 429.

I think an additional case should be added:
case perfStandbyOK && perfStandby:
code = activeCode

[drewmullen]

i actually had a very similar issue pop up

if your cluster is uninitialized:
https://10.x.x.x:8200/v1/sys/health?performancestandbycode=200&uninitcode=200 returns 501

however
https://10.x.x.x:8200/v1/sys/health?uninitcode=200&performancestandbycode=200 returns 200

the 1st combination was working at some point (at least around 1.1.1 i can confirm) but isnt on 1.1.3

i have a hashi support ticket opened for this issue already: https://support.hashicorp.com/hc/en-us/requests/17886?page=1