New: Expose context

[aegyed91]

If context is a non empty object, expose it intoJSON.

After inspecting the code I found the best solution would be to include context, in the response. Internally the module does not place sensitive information on context.

On second thought, this could leak sensitive information in applications relying on context being excluded in response. They might utilise this for internal logging. In this case, logger should either introduce a breaking change and bump major version, or introduce an extra option exposeContext with default value of false.

fixes #80
ping @DonutEspresso @ltvolks @maoueh

[coveralls]

Coverage increased (+0.03%) to 98.214% when pulling 4d23f72 on tsm91:feat/expose-context into ebe71cc on restify:master.

[coveralls]

Coverage increased (+0.03%) to 98.214% when pulling 4d23f72 on tsm91:feat/expose-context into ebe71cc on restify:master.

[coveralls]

Coverage increased (+0.03%) to 98.214% when pulling 4d23f72 on tsm91:feat/expose-context into ebe71cc on restify:master.

[coveralls]

Coverage increased (+0.04%) to 98.222% when pulling 6ae62ca on tsm91:feat/expose-context into ebe71cc on restify:master.

[coveralls]

Coverage increased (+0.04%) to 98.222% when pulling 6ae62ca on tsm91:feat/expose-context into ebe71cc on restify:master.

[coveralls]

Coverage increased (+0.04%) to 98.222% when pulling 6ae62ca on tsm91:feat/expose-context into ebe71cc on restify:master.

[aegyed91]

On third thought. This is not needed.

The only reason i wanted to use this for is client side error metadata. BadRequest already tells its a client side error. Client should validate form before submission, and be able to act upon BadRequest w/o metadata as well

[DonutEspresso]

Glad you found a solution @tsm91 👍 We've had continuing conversations around this, but ended up not serializing context by default exactly for the reason you mentioned re: leaking potentially sensitive context. That said, a custom toJSON() can be implemented if absolutely needed.