State: KeysLike

[JoshVanL]

// KeysLiker is an optional interface to list state keys with an
// optional SQL style wildcard pattern.
type KeysLiker interface {
	KeysLike(ctx context.Context, req *KeysLikeRequest) (*KeysLikeResponse, error)
}

type KeysLikeRequest struct {
	// Pattern is the SQL LIKE pattern to match keys against.
	Pattern string `json:"pattern"`

	// ContinueToken is an optional parameter to indicate the key from which to
	// start the search.
	ContinueToken *string `json:"startKey,omitempty"`

	// PageSize is an optional parameter to indicate the maximum number of keys
	// to return.
	PageSize *uint32 `json:"pageSize,omitempty"`
}

// KeysLikeResponse is the response object for getting keys like a pattern.
type KeysLikeResponse struct {
	Keys []string `json:"keys"`

	// ContinueToken is an optional token which can be used to continue the
	// search of keys. Usually only present if a `PageSize` was set on the
	// request.
	ContinueToken *string
}

PR adds a new state store API KeysLike, which allows listing keys
which match a given SQL LIKE style wildcard pattern ("%" and "_"). This
API is implemented currently solely to enable the workflow instance
listing functionality in Dapr, however could be exposed to the general
state APIs in future.

The request takes and requires a input Pattern field which is used to
match keys on. Also accepts an optional PageSize to limit the number of
results returned, and a ContinueToken to continue listing from a
previous request page.

Only returns the keys as a string slice. This function does not return
any values. Naturally, some state stores have better/more efficient
support for SQL LIKE style key queries.

Adds support for state stores:

• PostgreSQL (v1 and v2)
• MySQL
• SQLite
• SQL Server
• CockroachDB
• MongoDB
• Redis
• etcd
• In-Memory

Notes:

Both postgres v1 and v2 have a new migration to add a row_id column,
which is a unique identifier for each row. This is used to page results
efficiently and consistently.

The in-memory store now tracks an internal id for each key/value pair to
allow consistent paging when keys are added/removed during listing.

MySQL also introduces a new row_id column in migration for the same
purpose.

A new state feature FeatureKeysLike has been added to signal
KeysLike API support.

A conformance test has been added to test the KeysLike API for all
supported state stores.

[javier-aliaga]

LGTM

[cicoyle]

mostly lgtm just a few comments