Ensure that a variable is used in the path when using request_uri, and do not warn on proxy_pass_normalized if request_uri is used

[MegaManSec]

In my previous PR, I messed up the "valid" proxy_pass directive.

location /1/ {
  rewrite ^ $request_uri;
  rewrite ^/1(/.*) $1 break;
  return 400; # extremely important!
  proxy_pass http://127.0.0.1:8080;
}

will cause the backend server to receive a double-encoded path.

The correct configuration should be:

location /1/ {
  rewrite ^ $request_uri;
  rewrite ^/1(/.*) $1 break;
  return 400; # extremely important!
  proxy_pass http://127.0.0.1:8080/$1; # or http://127.0.0.1:8080$1; -- http://127.0.0.1:8080/ will NOT work and http://127.0.0.1:8080; will NOT work, as they will produce double-encoded paths.
}

This PR fixes that. It ensures that a warning is only shown if proxy_pass is used with a path and $1 is not set to $request_uri.

It also warns if $request_uri is used, but no variable is actually set in the proxy_pass directive (which will now warn on anybody that used my incorrect solution)

[dvershinin]

@MegaManSec can you please add those configs above to test and fp test?

Also would be great to heavily comment them e.g. with request URL and received by backend URL example, to fully understand what the type of config does.

I had used similar configuration elsewhere and no longer understand what it does with those rewrites and the need for return 400, etc. :-)

[MegaManSec]

Great idea. Note, I will rebase when I'm done, too.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[MegaManSec]

All done. Apologies for the spam due to the 20 commits.

[dvershinin]

@MegaManSec great and thanks!