This reverts commit ef36c5fd.

All a bit too involved right before a planned release.

Also, convert to PSR-2 where that was still lacking in these files.

also add some tests ;)

Sometimes there are issues with the metadata itself (e.g metadata
expired). These issues cannot be easily determined, due to the
Exception messages being dropped. In these cases, the current 'not
found' message can be ambiguous.

bugfix: NameIDs are created now as objects, so their information can't any longer be accessed as an array.

The _authSource column stores FQDNs. Increase the VARCHAR size from 30
to 255 since this is the maximum allowed length of a FQDN (RFC1035).

Also, increase the TableVersion to 2 and MODIFY the column size of
existing version 1 tables.

Fixes #579

The sspmod_saml_SP_Logout_Store::logoutSessions() method was still expecting the NameID to be an array.

This enables too the implementation of additional contact attributes, as requested in #509 to support the SIRTFI framework.

bugfix: Make sure a persistent NameID is not generated by default when the UserID is missing in the state array.

This allowed misconfigured IdPs (i.e. those without both a PersistenNameID authproc filter, a “userid.attribute” configuration option and no “eduPersonPrincipalName” attribute available after running all the authentication processing filters) to generate a persistent NameID based on “null”, effectively giving all users the same identifier.

- Variables possibly undefined when first used.
- Usage of XMLSecurityKey class without proper namespace.

This resolves #530. There are two problems here:

- When only one SubjectConfirmation is received and it is empty, an error should be thrown. However, the error would be a not very descriptive message warning about access to a non-property in a null object. Something more descriptive should be in place.
- Additionally, in PHP 7.0 this is an error and not an exception, and then the code continues to execute, effectively allowing assertions without a proper SubjectConfirmation element. This is wrong according to the standard.

This resolves #519.

The $store and $params variables were not initialized before trying to execute the prepared statement.

This resolves #519.

bugfix: When generating a NameID from a multivalued attribute, a warning was logged but the NameID was still generated.

Even though the default "exact" is used by most people, and few products support anything else, there's people asking for this.