[DBPW 2/5] Create middleware for Database v5

[pcman312]

Overview

This PR is part of a larger feature adding support for password policies into the combined database engine. This feature is being split into multiple PRs to make for smaller reviews & earlier feedback.

Adds middleware for Database v5. This includes the same middleware as Database v4 (tracing, metrics, and error sanitization). The error sanitization has some bug fixes from the v4 version (like not panicking and only accepting a map[string]string instead of a map[string]interface{})

Database v4 version: sdk/database/dbplugin/databasemiddleware.go

Prerequisites

• [DBPW 1/5] Add Database v5 interface with gRPC client & server #9641 merged
• Change base branch to master

Related PRs

Original password policies PR
1/X - Database interface & gRPC
3/X - Plugin handling
4/X - Database engine

[calvn]

I think I know why we're returning a concrete object here (not really modifying the object's fields after instantiation) and why we're not dealing with pointer receivers for its methods, but can you elaborate to confirm my assertions?

Since this is a middleware and likely to be passed around and reference as an interface, I am not sure if this can be problematic upstream at some point if the caller expects a pointer value.

[pcman312]

You nailed it: the middleware isn't changing after it is initially created. Passing it around under an interface type won't change any behaviors here. All interface types eg var db Database are implicitly pointers so you can do things like nil checks, however the underlying object such as DatabaseErrorSanitizerMiddleware can be a concrete, non-pointer type without issue. Since the middleware type is never manipulating its own variables in any of its functions this won't cause any problems.

[calvn]

Are there any cases where you'd need to type assert on the interface to a typed pointer value followed by a nil check?

[pcman312]

None that I've found. All of the usages of this use the V4 version of this use it as the Database interface, not as the underlying middleware type.

[pcman312]

FYI: the force pushing is due to rebasing against the dependent PR #9641. Once that PR is merged & the base branch is updated to master the force pushing will cease.