Use String::RawSizeMaxXXX() to limit String length

[somecookie]

This replacement aligns Ftp::Server with Ftp::Client code after recent
commit 0a261cb that introduced reusable String::RawSizeMaxXXX()
function for limiting the length of input tokens that may be converted
to String objects. This change effectively doubles the previously
anonymous 32KB limit for received FTP command parts (assuming
request_header_max_size is using 64KB default or a larger value).
String::RawSizeMaxXXX() classifies the increased limit as safe.

Also replaced anonymous 32KB limit in HTTP X-Forwarded-For request
header field building code, for the same reason.

No other suitable replacement candidates are known in current code. The
following seemingly similar hard-coded limits serve other purposes; they
would be needed even after the String class is gone from Squid code:

• 32KB Ipc::Mem::PageSize(): Strings are not stored in shared memory.
• 64KB BodyPipe::MaxCapacity: BodyPipe uses MemBuf, not String.
• 64KB Store::SwapMetaFieldValueLengthMax: CheckSwapMetaUrl() and
  similar Store swap metadata iteration code uses raw memory pointers,
  not String. UnpackNewSwapMetaVaryHeaders() uses SBuf, not String.
• 64KB limit in TeChunkedParser::parse(): We use SBuf, not String for
  TeChunkedParser::mimeHeaderBlock_ storage. The hard-coded limit
  prevents excessive trailer fields accumulation. Other grabMimeBlock()
  callers already use admin-configurable limits that may exceed 64KB.

This is a Measurement Factory project.

[rousskov]

Thank you for this cleanup and a careful evaluation of Squid code to find all String::RawSizeMaxXXX() candidates.

[rousskov]

I support the removal of the stale comment above. A part of that comment no longer matches Squid code -- 64KB is not the current String limit. Another part cites a now-obsolete RFC (and is already marked not to "matter"). Using String::RawSizeMaxXXX() makes this code self-documenting (among other advantages).