s3:loadparm: Ensure to truncate FS Volume Label at multibyte boundary

s3:loadparm: Ensure to truncate FS Volume Label at multibyte boundary

For FS_VOLUME_INFO/FS_INFO operation, a maximum of 32 characters are
sent back. However, since Samba chops off any share name with >32
bytes at 32, it is possible that a multi-byte share name can get chopped
off between a full character. This causes the string decoding for unicode
failure which sends back NT_STATUS_ILLEGAL_CHARACTER (EILSEQ) to the client
applications.

On Windows, Notepad doesn't like it, and refuses to open a file in this
case and fails with the following error:

  Invalid character. For multibyte character sets, only the leading byte is
  included without the trailing byte. For Unicode character sets, include
  the characters 0xFFFF and 0xFFFE.

Proposed fix:
- Find the last starting point of a multibyte codepoint if the character
  at 32nd byte is a subsequent byte of a MB codepoint.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=13947

Signed-off-by: Shyamsunder Rathi <shyam.rathi@nutanix.com>
Reviewed-by: Hemanth Thummala <hemanth.thummala@nutanix.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
(cherry picked from commit 0fa490e8476a2a5020ff2c253167b8a9454e8b97)