Stop initialising the IsUnexpected flag to false for new errors

[mattcottam-monzo]

The IsUnexpected flag has predominately been designed to support the case that you have an "expected" error (e.g. validation errors that would lead to a 400-like error code) that should actually be seen as "unexpected" (e.g. because the params being validated come from code and not user input), and so fail more noisily.

However there is also a sort-of-opposite scenario, where an "unexpected" error wants to be perceived as "expected". An example might be a downstream error from Service B bubbling up to Service A, where Service A handling this error doesn't need to also fail noisily in certain circumstances (e.g. a different team owning each service, where the error will just be noise to the owners of Service A).

This flag has the potential to support this second scenario too, as it has 3 values: nil, true or false. However, we currently initialise all new errors with false, meaning in reality this flag will never be nil, and it's impossible to differentiate between "expected" errors and "normal" errors (ones where we've not set this flag either way, and the normal logic should apply).

This PR changes the default for new errors to not initialise this flag (i.e. it will be nil). This should be a safe change, as long as any calling logic handles the potential nil pointer correctly already - you should check this before pulling in this change.

[mattcottam-monzo]

Felt it was worth adding a note here. Not changing this means this change should have no practical impact for someone relying on this function (we defaulted to false -> false, now we default to nil -> false).

Longer term I question if we really want this function, or perhaps we should have an equivalent Expected() function (that returns true only if the flag is set to false). But that risks making this more of a breaking change.