Protecting a branch via the API overwrites web UI push/merge permissions incorrectly

Summary

The branches API allows branches to be listed, created, deleted, protected and unprotected via API calls. Unfortunately, the functionality for protecting branches over the API is not as sophisticated as that of the web UI. Simply, via the API, it's only possible to configure whether users of role Developer can push/merge to protected branches, while via the Web UI it's possible to configure whether No-one, Masters or Masters + Developers can push or merge respectively.

The bug is that if you've set up that No-one should be able to push to a protected branch via the web UI, then attempt to configure the branch protection via the API, setting developers_can_push to false, it'll turn ON push permissions for Masters. Same thing for merge permissions obviously. This means that branch protection cannot be reliably configured via the API for users who desire No one to have push access to protected branches.

This is present in both v3 and v4 versions of the API.

Steps to reproduce

1. Create a new protected branch via the web UI. Set push permissions to No one.
2. Attempt to protect the branch via the API call. Set developers_can_push to false.
3. The push permission setting is now Masters.

What is the current bug behavior?

Setting developers_can_push to false sets Masters to push permission on protected branches.

What is the expected correct behavior?

Ideally I would like the same granularity in the API as there is over the web UI, but even without that, setting developers_can_push to false should NOT set the push permissions to Masters.

Output of checks

This bug happened on a githost.io instance running Gitlab 9.0.