multi: user reputation

[buck54321]

Conceptual

This PR introduces reputation, which is virtually identical to the ban score we had before, but with different semantics.

The reputation is actually three numbers. Here's the msgjson type.

// Reputation is the user's reputation breakdown.
type Reputation struct {
	Score     int     `json:"score"`
	RawScore  int32   `json:"rawScore"`
	Privilege float64 `json:"privilege"`
}

In addition, there is now a baselineScore, which functionally identical to the defaultBanScore and is used to give some buffer against penalty to new users. The baselineScore is also used to separate the user's score into two distinct regions, probationary and privileged. A user with a RawScore > baselineScore is considered a privileged user, and is eligible for increased limits on order placement. The extra order capacity increases linearly from ProbationaryLots to PrivilegedLots as the user's score increased from baselineScore to maxScore . A user with a 0 < RawScore < baselineScore is considered probationary, and has a low and constant taker lot limit of ProbationaryLots until they get their score back up. RawScore <= 0 is account penalization.

The users initial score is baselineScore, which is kind of like "waiving the probationary period", so there is a slight inconsistency in the terminology there, but I'm okay with it.

The RawScore is pretty much the ban score or auth.userScore from before. It can be used for independently tracking or auditing the reputation for an account client-side (not done in this PR). The Score is the RawScore normalized on (0, 100), and is meant for display. The Privilege is a float on (0.0, 1.0) that progresses linearly with the users score from the baselineScore to maxScore.

Technical

This is mostly a straight refactor, but there are two notable changes.

1. User's active swap limit is now based on the user's global reputation score and the market-level configuration (ProbationaryLots and PrivilegedLots).
2. Pre-image successes now contribute +1 to user raw score. I think this helps with self-consistency in the scoring system and helps users get their reputation up a little faster. I would like to take this a step further and assign order outcome scores as (preimage_miss = -2, cancel = 0, filled = + 1), so that cancels are considered in the user's reputation, but cannot themselves trigger a violation. This would have to be considered in the bigger picture of existing cancellation ratio penalties, so I haven't done that here yet.

Reputation tracking and associated types are moved from auth to dex and the methods have been refactored to take only builtin or dex types, e.g. no db.MarketMatchID. The idea here is that the client should be able to independently track their own reputation.

The market's taker lot limits are sent in the config response. The user's reputation is sent in the connect response, and then as a notification every time it is updated.

[chappjc]

I'm still on board with the gist of these changes, especially in a tiered framework introduced in #1120.

One thing to note about #1120 is that I've merged the cancel rate outcome tracking into the score computation instead of having it as a separate banable item. I've also made a TODO in the Connect result with a violations slice, but it can also work like this with Reputation, perhaps with details of the outcomes that impacted the user's score.

I feel like the way forward it to first merge the hd keys PR (#1015), then fidelity bonds with tiered accounts (#1120 ), then this to complete it (if we feel like this one is still the way forward and not just concept).

[buck54321]

I've merged the cancel rate outcome tracking into the score computation

Love it.

[buck54321]

@chappjc, @martonp, @JoeGruffins. Could I ask you for a concept ack on the game plan here before proceeding to adapt?

[buck54321]

Things are different with bonds. Closing.