Add validation constraints to contact.settings

That looks pretty good to me. No remarks; as far as I'm concerned that's RTBC. I suspect the test failure is a random failure, but I don't have permission (seemingly) to re-run the failed job...

So if you can re-run that job, and it passes, consider this me RTBCing.

The tests are passing now.

The descriptions/labels of the config are very vague, but that's a pre-existing issue.

Unfortunately that means that the validation constraints here turn out to be kinda nonsensical. Defining the minimum for user.flood:ip_window to be 1 is absurd:

   * @param int $window
   *   (optional) Number of seconds in the time window for this event (default is 3600
   *   seconds, or 1 hour).

So we're saying that the minimum window is 1 second. Why does that make sense?

The purpose of these config validation issues is not to blindly add validation constraints, but to first understand the configuration and how it is interpreted by the associated code/APIs, and then define sensible validation constraints.

Unfortunately that was a step in the wrong direction … so I explained how you can start moving this in the right direction: https://git.drupalcode.org/project/drupal/-/merge_requests/7469/diffs#no... 😊

Think your last comment does seem reasonable, guessing we could work with that.

Handled all the comments and rebased. Think this is ok.

I think this looks good, I don't think we need specific test coverage for these values.

I wonder if we should ask for a user module maintainer for a review? Will ping kristiaan.

I pinged kristiaan in slack, and in the meanwhile I figured there may be something else that we could do.
Instead of doing a min check here, we just need to know that the value is > 0, because smaller is not an option.

So I think isPositive might be a simpler way to validate this instead of being this specific.
However, waiting to put this back to needs work based on feedback.

Gave some preliminary feedback on Slack, if it's not enough then we can quickly have a look in person in Leuven a week and a half from now. My only concern is that a too loose validation would allow config to contain values that the code does not handle well (or at all). So as long as that concern is taken care of, I'm fine with this.