Fix revoking a scoped token from an unscoped token

When a scoped token that was created from an unscoped token was
revoked, the original token wound up being revoked. This is because
the scope wasn't included in the revocation event. By including the
scope in the revocation event only the scoped token is revoked.

Change-Id: I5652663ab7e1176d3b1efc5d218a8a020498067e
Closes-Bug: #1347318
Fix revocation event handling with MySQL

When MySQL is used to store revocation events, events are returned
from the database with the timestamps truncated to the second. This
causes a revocation event for a token (which has the issued_at
timestamp to the microsecond) to not match the revocation event and
therefore the token is not considered to be revoked.

The fix is to have the revocation events and token timestamps both
always be truncated to the second. This will cause all tokens for a
user that are issued within a second to be revoked when any of those
tokens are revoked, which shouldn't be a problem.

Change-Id: Ibd82b4ce910206dfd504c396614ae2ebed025e9b
Closes-Bug: #1347961
Improve instructions about federation

This patch clarifies two elements:

1. According to Shibboleth's documentation the ShibRequireAll command
is not supported on Apache 2.4+, details can be found at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig

2. Some configurations of Apache + Shibboleth SP will always set the
REMOTE_USER env variable, even if it is an empty value; this can
lead to unexplained authentication errors that can be avoided if the
external auth method is disabled.

Change-Id: Iaf4e57e7e3d79a2e87e805bbe8340861ee9c3db3
Merge "Fix revoking a scoped token from an unscoped token"
Merge "Improve instructions about federation"
Merge "Fix revocation event handling with MySQL"