Use Charset instead of String for Protocol#CHARSET

[JarvisCraft]

Description

This replaces the type of Protocol#CHARSET with Charset type which is less error-prone to use and initializes it with a constant from StandardCharsets.

This also updates all (2) usages which relied on String being used (i.e. try-catch are removed as they were catching UnsupportedEncodingException).

Motivation

Using Charset instead of raw string allows less error-prone code and allows to omit unneeded UnsupportedEncodingException catching.

Problems

This is technically a breaking change as API users relying on this field type being of type String may have the following incompatibilities:

• source: if someone used the String value such as by using Charset.forName(Protocol.CHARSET) than this calls will no longer compiler

• binary: if the compiler used by them failed to inline the constant (although it had to) then getstatic may fail, although it is very unlikely as the inlining compiler behaviour is specified

However, as the next version (4.0.0) is going to be a major release, such impact is SemVer-compatible and its impact is not that serious and old code can be easily refactored.

Alternatives

• Introduce a new constant: add something like

public static final Charset CHARSET_OBJECT = StandardCharsets.UTF_8;

to hold the Charset-typed object, but it is counterintiutive and leads to dependency on legacy / not-that-good API design flaws.

• Do nothing: rely on current String field

[yangbodong22011]

LGTM for 4.0.0