The old privatekey_pass was (wrongly) expected to be reused for the new
privatekey_pass. That prevented my SP from loading the new_privatekey.
Users could not log in from entities using the new key.

Clarify that the new key needs a new_privatekey_pass entry.

Co-authored-by: Marko Ivančić <marko.ivancic@srce.hr>

* Add SubjectID authproc

* Add PairwiseID authproc

* Add tests

* Conform SAML2INT; check AuthnRequest signature unless specifically disabled

* Migrate email utils to non-static

* Migrate http utils to non-static

* Migrate net utils to non-static

* Migrate random utils to non-static

* Migrate system utils to non-static

* Migrate time utils to non-static

* Migrate xml utils to non-static

* Upgrade notes

* Update test-framework

* Fix tests

* Migrate array utils to non-static

* Migrate attribute utils to non-static

* Migrate auth utils to non-static

* Migrate config utils to non-static

* Migrate crypto utils to non-static

* Raise coverage

* Fix rebase issue

Closes: #1430

* Start testing on PHP 8.0

* Update test-framework

* Fix broken unit tests

* Fix query; apparently under PHP8 the query would raise PDOException instead of returning false

Co-authored-by: Tim van Dijen <tvdijen@gmail.com>

eduPerson recommends: 'Multiple "@" signs are not recommended, but in any case,
the first occurrence of the "@" sign starting from the left is to be taken as
the delimiter between components. Thus, user identifier is to the left,
security domain to the right of the first "@".'

Closes #236

This would otherwise terminate win an error because checkURLAllowed
does not accept a null parameter.