Check if account matches a known spammer does not work even if API returns a match

Problem/Motivation

The 'Check if this account matches a known spammer' button does not work correctly if the API of stopforumspam.com returns a match.

Steps to reproduce

• Use 8.x-1.0-alpha3
• Have an existing user whose email address is found in stopforumspam.com database
• Use the 'Check if this account matches a known spammer' button
• Observe that the result message of 'Check if this account matches a known spammer' says that this user is not a spammer
• Observe in Drupal logs that the response from stopforumspam.com indicates that this account is a spammer

Proposed resolution

With a quick glance, the issue seems to be in SpambotUserspamForm.php.

checkSubmit calls static::sfsRequestDataMessage which looks like this:

  public function sfsRequestDataMessage($request, $data, $field) {
    $messages[] = [
      'text' => $this->t("This account's @field address matches %num times: @link", [
        '@field' => $field,
        '@link' => Link::fromTextAndUrl($request[$field], Url::fromUri('http://www.stopforumspam.com/search?q=' . $request[$field])),
        '%num' => $data[$field]['frequency'],
      ]),
      'type' => 'warning',
    ];

This function does not return anything and the scope of $messages is that function only. So when we later in the checkSubmit try to add the messages to the messenger, $messages will be empty.

Remaining tasks

Why are we making a static call to sfsRequestDataMessage? Shouldn't we just make $messages a class variable and then say $this->messages all over the place?

Or alternatively change sfsRequestDataMessage returning the messages so that those would be appended to $messages where sfsRequestDataMessage is called. The code is kinda a mixture of object oriented and procedural code so either approach should do the trick if we keep the structure of the code like it is without refactoring it too much in the scope of this issue.

User interface changes

None.

API changes

None.

Data model changes

None.