feat(dbsql): Uniqueness and foreign key violation detections

[onelapahead]

Description

Callers that want to return a 409 when a row already exists currently either run a pre-insert existence query (which races against concurrent inserts and yields an opaque 500 for the loser) or string-match the driver's error text. Neither are what we want.

This adds Database.IsUniqueViolation and Database.IsForeignKeyViolation, which inspect the full error chain for an integrity constraint violation so callers can rely on the database constraint for enforcement and map the resulting error to a meaningful response.

For PostgreSQL, you can do something like:

import "lib/pq"

// ...

features.ConstraintViolationClassifier = func(err error) *dbsql.ConstraintViolation {
    var pqErr *pq.Error
    if errors.As(err, &pqErr) && (pqErr.Code == dbsql.SQLStateUniqueViolation || pqErr.Code == dbsql.SQLStateForeignKeyViolation) {
        return &dbsql.ConstraintViolation{SQLState: string(pqErr.Code), Constraint: pqErr.Constraint}
    }
    return nil
}

Register that in your DB. So then an Insert can look roughly like:

if err := someTable.Insert(ctx, aResource); err != nil {
    if db.IsUniqueViolation(err, "a_uniqueness_index_for_resource") {
        return nil, i18n.NewError(ctx, msgs.MsgResourceAlreadyExists)
    }
    return nil, err
}

so we can actually detect such specific violations and test them more thoroughly. For multiple uniqueness constraints,etc. we can use switch.

Behavior change

i18n supporting Unwrap is really really useful so when we do i18n.WrapError, we can still do error.Is(err, sentinel) for sentinel pattern errors (whether from other libs, or sentinel errors we create).

If there is code that relies on the unwrap not being supported, and has written itself as such thats a breaking change. But an edge case that could be considered a bug, and has made i18n have some limitations as I try to use it, I think its a breaking change that can be documented in a minor release since it is contained and small. And its behavior that is hard to rely on - you would have to have code that could either return i18n errors or unwrapped errors, and if conditions trying to distinguish/check for the unwrapped errors.

[onelapahead]

On the point about Unwrap, there's actually code in FireFly expecting Unwrap to be supported in order to detect wrapped errors:

• DefineFFI — https://github.com/hyperledger-firefly/firefly/blob/28b672fb543dd6fd68f81a33a2e3dbe329b88afd/internal/definitions/sender_contracts.go#L52-L60
• DefineTokenPool — https://github.com/hyperledger-firefly/firefly/blob/28b672fb543dd6fd68f81a33a2e3dbe329b88afd/internal/definitions/sender_tokenpool.go#L122-L130

So this would fix those bugs.