This PR fixes an rest api parity issue related to encoding paths in URL.

Actual behavior

Given the following invocation URL against a rest api (e.g., with {proxy+} integration and a lambda function as backend):

GET https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/user/test%2Balias@gmail.com/plus/test+alias@gmail.com?email=test%2Balias@gmail.com

• path: "/{stage_name}/user/test+alias@gmail.com/plus/test+alias@gmail.com?email=test%2Balias@gmail.com"
• queryStringParameters.email: test+alias@gmail.com

Expected behavior

The base path should not decode URL encoded characters such as %2B => + and looks like this in AWS: /user/test%2Balias@gmail.com/plus/test+alias@gmail.com

Implementation

Instead of relying on decoded request.path or request.full_path from Werkzeug, we need to compose the invocation path manually consisting of a non-decoded base part and a decode params part.

Questions

• When can url_params be None?
• Can we assume defaults for non-present stage and path variables or should we fail fast?
• Does the current solution work with custom domain names where the stage_name is omitted?
• Any other special cases to consider?