Summary of error handling

[Cantor, Scott]

This has gotten fairly involved, but that's what I wanted, not to have to
plow into this later and rip the design apart to make more advanced things
work.

At the top level, there's events and exceptions. Flows result in events,
and catastrophic errors result in exceptions. For events, it's largely up
to the flow design what to do, so this isn't SAML specific, but is a
decent model to copy in other cases. Exceptions are pretty much outside
the flow's control, so that's going to be uniform.

On the back-channel events are almost always SAML responses, because the
new code can generate those as long as there's a socket still open to send
back something. I think V2 might have returned SOAP faults in some cases,
but I don't think this is very crucial.

On the front-channel, events are either Local or not. A Local error stops
the profile at the IdP, and won't issue a SAML response. A non-Local error
tries to return a SAML response if there's sufficient binding/endpoint
material to do so, and if not falls back to Local. By default, all errors
are non-Local unless config is changed to trap them Local.

For a SAML response, the status codes are determined based on the event.
The message is either defaulted, or if there's an option flipped, the
event can be mapped into a message using the Spring messages.properties
file.

For a Local error, the event can be mapped into a view template. I was
using different templates this afternoon, but that's just going to create
a look and feel maintenance mess, so I collapsed that by default into one
template that uses the messages file to map the event into the text to
insert into the template. This is all very "by-convention" and isn't a
design assumption, just one way of doing it. Events can still be mapped to
their own templates if desired.

Using the messages file that way provides limited i18n support for free,
because Spring will look for locale-specific files before using a default
one, and I tested that. Unfortunately they lazied-out on that support and
only allow a single locale to be fed into the lookup, so that means the
top locale choice either fits, or you get a default; it can't search
through all client locales for a better match. I don't think we should
implement that, at most we should file a bug and let Spring fix it.

Lastly, exceptions trigger a Spring extension I added that works like the
existing MVC handler that maps exceptions to views, but I added code to
populate the view model with some data from the request so that the
template can actually do useful work. I merged that code into the
event-based template so it's uniform, and if there's no WebFlow context,
it checks for an exception from MVC, and uses that class name to lookup
the message to display.

I've only coded Velocity so far, since JSP views can always do anything
Velocity can much more easily.

-- Scott