Test more characters in state

On today's FAPI WG call https://bitbucket.org/openid/fapi/issues/610/ability-for-as-to-reject-requests-that was discussed.

The conformance suite currently only tests alpha numeric state values, and requires servers to correctly process 128 character states. There is also a test that uses a 384 character state, but in that case the server is allowed to reject as we don't have any normative text or agreement that servers must accept 384 characters (i.e. the test only checks that the server doesn't silently truncate/corrupt the long value).

Dave Tonge pointed out that it's common to use JWTs for state and suggested we should consider switching from alphanumerics to the base64url character set. Probably it's best to do this only when using the 128 character state, and to do it by statically including every base64url character (or at least the non-alphanumeric ones) into the string. (Because if we do expect the non-alphanumeric characters to cause an issue, it's important that they are used in every run of the test, otherwise the test may pass on some runs and fail on other runs without anything actually changing, and we'd want the test to consistently fail if base64url characters are being mishandled.)

We should probably do some kind of update to the RP tests as well. Unfortunately without normative text it is pretty hard to fail RPs that use weird [not-url-safe] characters in their state/nonce - e.g. RFC6749 ( https://www.rfc-editor.org/rfc/rfc6749#appendix-A.5 ) explicitly defines state to be anything in the 0x20 - 0x7E characters (and we probably should fail RPs that use characters outside that range). I think we can at least issue a warning if the main happy flow test if they use non-url-safe characters, with a message suggesting it's likely to be bad for interoperability. We can probably do the same if they use a state over 128 characters too.