JwtParser 自定义验证器

由于这种变化性，本问题的创建是为了跟踪引入新方法（或方法）来指定自定义验证器所需的工作。例如： `validate(String claimName, Predicate<Optional<T>> condition)`: - 请求头键可能存在也可能不存在，`Optional.isPresent`将指示其存在。此外，可以评估 null 与非 null 的区别。 这可能是任何给定请求头的核心验证方法。我们可能添加以下额外的便利方法： `requirePresent(String claimName)` - 仅保证映射键存在。值可能为 null 或任何其他值。 `requirePresent(String claimName, Predicate<T> condition)` - 保证映射键存在。只有在键存在时才会评估 `condition`。如果键不存在，验证仍然成功，但 `condition` 将不被评估。 `require(String claimName, Predicate<T> condition)` - 保证映射值存在且不为 null，然后再评估 `condition`。如果缺失或为 null，则在解析期间抛出异常。 (或类似)。如果它们存在，它们很可能会调用 `validate(String claimName, Predicate<Optional<T>> condition` 核心方法。 所有这些方法的设计仍然是未知的，但这应该是一个很好的起点。 此外，有时验证可能需要检查多个请求头，例如： `enforceClaims(Predicate<Claims> condition)` (或类似)。 此外，应该提供一组预置的谓词，以简化人们的工作，例如： `Validators.exists()` 返回一个 `Predicate<Optional<T>>`，如果可选值 `.isPresent()` 为 true，则返回 true，否则返回 false。 其他潜在的 `Validators.*` 静态方法： * `notNull` * `isNull` * `not` (不等于) * ... ? 请注意，这些方法暗示 Java 8 语法，但这并不是绝对必要的。如果我们可以使用 lambda 来实现此功能，将会节省大量工作和努力。鉴于这已经是大多数 JDK 应用程序的核心，创建自己的类似接口来模拟 lambda 以强制正确的 API 使用将是一个艰难的选择，而且这听起来并不令人满意。 实现说明：基于 #473，这些方法应仅添加到 JwtParserBuilder API，而不是现有的 `JwtParser` API，以强制正确的 API 使用 ...