Enforce user rights while rejecting a requisition

Probably, It was my fault. All works.

Summary:
1. When APPROVE_REQUISITION right is assigned, user is allowed to approve or reject the requisition.
2. When user tries to approve requisition without that right, 403 is returned.

The APPROVE_REQUSITION right allows to reject the requisition. When right is not assigned to user, 403 is returned. However after rejecting the requisition, I can submit those requisition only by API (administrator can do that). On UI, the view of requisition contains APPROVE button.

Steps to reproduce:
1. As an devadmin try to reject the requisition for facility: Comfort Health Clinic, program: Family Planning (using API).
URL: http://test.openlmis.org/api/requisitions/c6ce0209-6caf-4f40-bea8-01ce529fdc67/reject?access_token=0247470a-c030-48e2-9b2d-747700c60314
Method: PUT

(asisgned roles)

2. Log in into UI as administrator, view the requisition details. APPROVE button is shown.

I just talked with Mary Jo and Josh. We all agree that the logic for Reject should check the APPROVE_REQUISITION right. It turns out that V1 did not even have Reject, apparently; and we agree that we want to change from how V2 worked. We believe in V2 all the users who had APPROVE_REQUISITION right also had all of the *_REQUISITION rights. So anyone who could get into that screen would have the full set of permissions to do everything anyway.

But in V3 we believe it makes the most sense to specifically have the /reject endpoint check the APPROVE_REQUISITION right. I will update the ticket to specify that.

I checked v2 and the right required to reject a requisition there is "CREATE_REQUISITION". It seems that it would make more sense if the right was "APPROVE_REQUISITION", meaning that if you can approve requisition you can also reject it. I was not sure if there was any reasoning for the right to be "CREATE_REQUISITION" so I left it blank for now.
CC