Accessing a key in an array is not allowed when the array is not a variable but a value returned by a function.

This also required adding an additional argument to
SimpleSAML\Utils\Crypto::loadPrivateKey to ease in testing. Without
this additional argument, SimpleSAML_Configuration::getBaseDir eventually
gets called to determine the private key location.  This doesn't work
well with vfsstream. This argument shouldn't cause too much trouble, and
seems cohesive enough with the function's purpose.

Formatting, namespaces, phpdoc.

This resolves #476.

It is possible that the current script ($_SERVER['SCRIPT_FILENAME']) is inside SimpleSAMLphp's 'www' directory. However, even if that's the case, we should not enforce our base URL (as set in the 'baseurlpath' configuration option) if the request URI ($_SERVER['REQUEST_URI']) does not contain the relative path to the script. This is the case of AuthMemCookie, for example, where accessing a random URL protected by Apache, leads to the execution of a SimpleSAMLphp script, where SimpleSAML\Utils\HTTP::getSelfURL() must not try to be smart when guessing the current URL.

Now we are finally using the 2.x branch of the SAML2 library, which was also migrated to use namespaces. Even though the library provides an autoloader that allows loading the classes with the old names using class aliasing, we need to do the migration in one commit (at least for most part of it). This is due to the way SimpleSAMLphp checks data types, using inheritance to check objects agains abstract or more general classes. Even though class aliasing works, there's no way to replicate those relationships, and type checks that use the old class names will fail because the aliases are virtually new classes that don't inherit from others.

Recent fixes for URL guessing and building addressed bugs in the code that were preventing the 'baseurlpath' from being used properly. However, they introduced a new issue, as the code was assuming the current URL would always point to a SimpleSAMLphp script. This is not always true, of course, as any script can invoke our API and end up trying to get its own URL (for example, when calling requireAuth()).

In order to fix this, we monitor mismatches between SimpleSAMLphp's installation path and the absolute, real path to the current script. When there's a mismatch, it means we are running a third-party script outside SimpleSAMLphp, and therefore we should NOT enforce 'baseurlpath'. This introduces an additional issue, as applications behind a reverse proxy may cause trouble to guess the right URL (we will use the URL as seen by SimpleSAMLphp in the server, which is not necessarily the same as the user sees with a reverse proxy in between). For the moment, we'll leave the responsibility to sort that issue out to implementors. It might be a good idea to add a page to the wiki explaining how to do this.

This resolves #418.

Now that we are using realpath() to try to obtain the URL relative to the base URL path of SSP, we need to use real scripts or realpath() will return an empty string.

Fix the tests to handle the new, more permissive behaviour of SimpleSAML_Configuration::getBaseURL(), and add tests for getBasePath() too.

Change the implementation of SimpleSAML\Utils\HTTP::getSelfURL() and getSelfURLNoQuery() to honor the 'baseurlpath' configuration option instead of simply using the environment. They were actually broken since they were using it to build the scheme, host and port, but completely ignoring the path, rendering wrong URLs in between what was configured in 'baseurlpath' and the real information in the environment. This resolves #396, but also affects #5. The changes to getSelfURLNoQuery() in #391 are unnecessary now, since we now basically getting the full URL and remove the query afterwards.

Fixes #379

Start using the new configuration exceptions, handling error situations that before led to blank pages or even worse.