Gitlab::UrlBlocker: Ensure absence of URI scheme with `schemes: :none`

What does this MR do and why?

This MR allows passing schemes: :none to Gitlab::UrlBlocker to ensure the absence of URI schemes.

For example:

Gitlab::UrlBlocker.validate!("example.com", schemes: :none)  # OK
Gitlab::UrlBlocker.validate!("http://example.com", schemes: :none)  # FAIL

This addition allows the use of addressable_https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/validators/addressable_url_validator.rb validator (which uses Gitlab::UrlBlocker beneath) for URI (plain hostnames) without any scheme.

See !114917 (comment 1320128257) for more context.

module ServiceDesk
  class CustomEmailCredential < ApplicationRecord
    ...
    validates :smtp_address,
      presence: true,
      length: { maximum: 255 },
      hostname: { allow_numeric_hostname: true, require_valid_tld: true },
      addressable_url: { schemes: :none, ascii_only: true, enforce_sanitization: true, allow_localhost: false }
  end
end

Previous solution (adding a virtual, private method) did not work as the resulting errors cannot be presented to users easily:

module ServiceDesk
  class CustomEmailCredential < ApplicationRecord
    ...
    validates :smtp_address,
      presence: true,
      length: { maximum: 255 },
      hostname: { allow_numeric_hostname: true, require_valid_tld: true }
    # Add additional validation via addressable_url for
    # combined schema + smtp_address + smtp_port that uses Gitlab::UrlBlocker
    validates :smtp_address_uri,
      addressable_url: { schemes: %w[smtp], ascii_only: true, enforce_sanitization: true, allow_localhost: false }
  end
end

This MR also fixes a couple 👮 offenses in a separate commit. Please don't squash.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.