ORA-61: Answer too long error message

[ORA-61](https://openedx.atlassian.net/browse/ORA-61)

It turns out that we were restricting *character* length on the client side (using the textarea's `maxlength` attribute), but checking JSON-encoded *byte* length on the server side (in the submissions API).  Depending on which characters were being encoded, a user could exceed the byte length limit without exceeding the character limit (for example, double-escaped newline chars, non-ASCII unicode, and JSON keys).

This PR addresses the issue in two ways:

1) It suppresses the "field errors" returned by the submissions API, which (a) weren't localized and (b) were a scary `repr` or a dictionary, which users should never have to see.

2) It intercepts "answer too long" request errors from the submissions API and displays the more specific error message: "Your answer is too long."  This is somewhat vague (it doesn't tell the user *how* long), but I think it's clearer than saying something more specific like "JSON encoded byte length > 100K", which the user doesn't have any control over.

There's a related PR in edx-submissions: https://github.com/edx/edx-submissions/pull/7
Once that is reviewed, merged, and released, I'll update the requirements to point to the new version in PyPi.

@srpearce Please review the messaging changes (all in `SUBMIT_ERRORS` on line 29 of `submission_mixin.py`)

@stephensanchez and @gradyward please review the code changes.
Hm, based on the serializers I guess that'd just mean that we'd have to do
this kind of parsing lower in the chain. Nevermind then.


On Wed, Jul 30, 2014 at 1:16 PM, Will Daly <notifications@github.com> wrote:

> In openassessment/xblock/submission_mixin.py:
>
> > @@ -80,10 +81,35 @@ def submit(self, data, suffix=''):
> >                      student_sub
> >                  )
> >              except api.SubmissionRequestError as err:
> > -                status_tag = 'EBADFORM'
> > -                status_text = unicode(err.field_errors)
> > +
> > +                # Handle the case of an answer that's too long as a special case,
> > +                # so we can display a more specific error message.
> > +                # Although we limit the number of characters the user can
> > +                # enter on the client side, the submissions API uses the JSON-serialized
> > +                # submission to calculate length.  If each character submitted
> > +                # by the user takes more than 1 byte to encode (for example, double-escaped
> > +                # newline characters or non-ASCII unicode), then the user might
> > +                # exceed the limits set by the submissions API.  In that case,
> > +                # we display an error message indicating that the answer is too long.
> > +                answer_too_long = any(
>
> Not without some pretty significant changes to how we're doing validation
> in the submissions API. We put the answer size check in Django rest
> framework serializers, and we rely on the serializers to tell us if a
> submission is valid. If not, we raise a request error.
>
> I'd also be worried about breaking backwards compatibility by introducing
> a new exception type, which other clients of the API might not be catching.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/edx/edx-ora2/pull/543/files#r15598015>.
>