Generalize DDP error handling for non-Meteor errors

[shilman]

To prepare an NPM-ready SimpleSchema 2 that is decoupled from Meteor, @aldeed proposes the following changes to the DDP server:

When an Error is thrown while executing code as part of an HTTP or Websocket request, catch and examine the Error instance. If error.clientSafe is exactly true, then error.name, error.message, error.error, error.reason, and error.details may all be assumed to be safe to include in the response sent to the requesting client. Alternatively, if error.sanitizedError is an Error instance, then error.sanitizedError.name, error.sanitizedError.message, error.sanitizedError.error, error.sanitizedError.reason, and error.sanitizedError.details may all be assumed to be safe to include in the response sent to the requesting client. The error stack should never be sent.

For context, see discussion here: https://forums.meteor.com/t/meteor-guide-methods/19662/40

Proposed updates:

• DDP server error handling
• Unit tests
• Documentation?

[tmeasday]

This seems reasonable to me.

In terms of docs:

• http://docs.meteor.com/api/methods.html#Meteor-Error
• https://guide.meteor.com/methods.html#errors

Are the obvious spots to fix.

[hwillson]

Keeping this feature request here for now (instead of closing/migrating it to meteor/meteor-feature-requests) as there is an open PR (#8756) against it.