[SDK-1405] Added support for new generic error details

[stevehobbsdev]

Changes

This PR adds support for new "blocked_reasons" error type, which includes more detail behind why a user has been blocked.

The details are surfaced in the error object as follows:

{
  code: 'blocked_user',
  description: 'Blocked user.',
  errorDetails: {
    codes: [ 'reason-1', 'reason-2' ],
    details: {
      'reason-1': {
        timestamp: 123786498
      },
      'reason-2': {
        timestamp: 127836389
      }
    }
  } 
}

References

Support for this was generated from an internal service desk ticket.

Testing

• This change adds unit test coverage
• This change adds integration test coverage

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All tests and linters described in the Develop section run without errors

[ademartini]

I think this looks good. @abbaspour, you had mentioned needing a new callback here?

[adamjmcgrath]

lgtm

[stevehobbsdev]

Thanks @adamjmcgrath. I've just read this is due a further change so I will hold off merging for now. Will need another review once those changes are made.

[madsharm]

A question - do we need to have this hardcoded check here on 'blocked_user'.
There might be benefits in making this code generic. If there are other cases in future that need to extend error responses via codes and details, then generic code will require no new code changes in Auth0.js.
Do you think it makes sense to check if error_codes and error_details are present, then just include them in the response object in generic manner ( and not wrap it in blockedUser object)?

{
code: 'blocked_user',
description: 'Blocked user.',
codes: [ 'reason-1', 'reason-2' ],
details: {
'reason-1': {
timestamp: 123786498
},
'reason-2': {
timestamp: 127836389
}
}
}

or

{
code: 'blocked_user',
description: 'Blocked user.',
errorDetails: {
codes: [ 'reason-1', 'reason-2' ],
details: {
'reason-1': {
timestamp: 123786498
},
'reason-2': {
timestamp: 127836389
}
}
}
}

[stevehobbsdev]

@madsharm I like the second option here, primarily because the first one has both code and codes at the same level on the object, which could be confusing.

Agreed with making it more generic though. Let me make some changes.

[stevehobbsdev]

@madsharm I made those changes in fcc484c

Let me know what you think

[madsharm]

LGTM and thanks for doing the change