[2.5/2.6] Nginx config issus resulting in CORS and other headers not working as expetced.

[defnull]

Describe the bug
When $bbb_loadbalancer_node has a value, then some headers are missing (problem A) and at other places, the expected CORS headers are not set (problem B).

Problem A) Nginx if blocks work in strange and sometimes very counter-intuitive ways, and add_header is especially unsafe to use in if-blocks. An add_header directive in an if or location block will cancel all add_header directives defined outside of the block. As a result the P3P header (IE workaround) for locations defined in web.nginx is missing if $bbb_loadbalancer_node is set. There might be more issues in other places, but this is the one I found.

Problem B): Support for $bbb_loadbalancer_node was not implemented in notes.nginx. Etherpad sends a blanket Access-Control-Allow-Origin: * but the CORS spec does not allow to send credentials in that case. An explicit origin is needed. As a result, the new "Move notes to whiteboard" feature won't work in a cluster using $bbb_loadbalancer_node. Browsers will perform the (expensive) request but then deny access to the result because of bad CORS headers.

A solution would be to unconditionally set add_header Access-Control-Allow-Origin $bbb_loadbalancer_node always; and add_header Access-Control-Allow-Credentials true always; without the guarding if-block. add_header does nothing if the value is empty, and the Access-Control-Allow-Credentials has no effect if Access-Control-Allow-Origin is not present, so this should work for all setups equally well. To get pads working, an additional proxy_hide_header Access-Control-Allow-Origin; is needed because otherwise there would be two headers.

I also noticed that web.nginx has a location /bigbluebutton block nested in another location /bigbluebutton block. Why?

While we are at it: Pads won't load in Safari due to their strict third-party cookie policy if the html5clieht and etherpad run on different domains. This is a different issue, but another place where $bbb_loadbalancer_node mode breaks.

Expected behavior
A cluster using a single front-end domain using $bbb_loadbalancer_node should work as documented.

Actual behavior
$bbb_loadbalancer_node has issues, resulting in breaking features.

BBB version:
2.5 and 2.6-alpha2

Additional context
Add any other context about the problem here.