…y() (#2943)

Newer Guava (pulled in transitively via resource-server 1.5.x)
annotates com.google.common.base.Function.apply() with @CheckReturnValue,
so ErrorProne now flags the two call sites that discard the return:

  uPortal-rendering/src/main/java/org/apereo/portal/portlet/container/
  cache/LimitingTeeWriter.java:86
  cache/LimitingTeeOutputStream.java:84

The callback's Function<T,?> return was always intentionally discarded
(the sole caller returns null), so the fix is to name the captured
result 'unused' — the convention ErrorProne recognizes as "intentional
discard" — with @SuppressWarnings("unused") to also silence the
compiler's own unused-variable lint.

Master CI passes today because its resource-server 1.3.1 pin pulls an
older Guava without the annotation; the check triggers on branches
that have bumped to resource-server 1.5.x+ (e.g. #2915
'Bootstrap / jQuery Update & Fluid Infusion Removal', which fails all
5 CI jobs on this exact error). Landing the fix on master lets that
branch rebase and go green.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

uPortal pins springVersion=4.3.30.RELEASE explicitly, but resource-server
1.5.x transitively depends on Spring 5.x. Without an exclusion, a build
bumping resource-server to 1.5.x ends up with both Spring versions on
the classpath and javac resolves org.springframework.web.util.UriUtils
against the Spring 5 API — where encodePathSegment(String, String) no
longer declares 'throws UnsupportedEncodingException'. The catch clause
in uPortal-utils-core's Util.encodePathSegment() then becomes unreachable
and compilation fails with:

  Util.java:143: error: exception UnsupportedEncodingException is never
  thrown in body of corresponding try statement

This is exactly the CI failure on #2537 (Renovate's resource-server
1.3.1 → 1.5.2 bump), and the fix originates from @Naenyn's #2915 where
this exclusion is part of a larger 193-file PR. Landing it independently
on master unblocks #2537 and any other branch bumping resource-server,
without coupling to the Bootstrap/jQuery work in #2915.

Exclusion policy mirrors what #2915 applies:
  - resource-server-api:  exclude spring-jcl (module-level) and all slf4j
  - resource-server-utils: exclude all of org.springframework and all slf4j

The narrower exclusion on resource-server-api reflects that it's a
smaller artifact; the broader exclusion on resource-server-utils
prevents the full Spring 5 web stack from riding along.

Verified locally:
  - master + this change (resourceServerVersion=1.3.1):
    :uPortal-utils:uPortal-utils-core:compileJava BUILD SUCCESSFUL
  - master + this change + resourceServerVersion=1.5.2 (simulated):
    :uPortal-utils:uPortal-utils-core:compileJava BUILD SUCCESSFUL
    (the Util.java error goes away)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: add v5.17.3 to CHANGES and HISTORY

Problem: v5.17.3 was just released. CHANGES.md (operator-relevant
upgrade notes) and HISTORY.md (per-version release index) hadn't been
updated for this release. CHANGES had been silent since v5.15.2 and
HISTORY hadn't been touched since v5.2.

Goal: capture the operator-facing impact of 5.17.3 (Bill's frontend
modernization affects customized skins) and start re-tracking the
5.17.x line in HISTORY.

Changes:
- docs/CHANGES.md: add a `## v5.17.3` block under "Next Release"
  flagging the Bootstrap/jQuery/Fluid Infusion modernization (#2915)
  and warning operators that customized skins will need updating
  (LESS → SCSS, BS3/4 class names → BS5, no more Fluid library).
- docs/HISTORY.md: add a `### 5.17` section listing 5.17.0–5.17.3
  with their release dates and tag links. Note above the section
  that 5.3–5.16 are not enumerated; deferred to the GitHub releases
  index. Backfill of those versions is out of scope here.

Notes: v5.17.3 itself is already cut and tagged — these are docs
catching up. Per the project's PR-first policy, sending this through
review rather than committing direct to master.

* docs: backfill v5.17.2 Java 11 floor in CHANGES.md

Problem: CHANGES.md is for deployment-impacting changes (Java/Servlet
bumps, DDL changes, mandatory property/cache additions). v5.17.2
bumped sourceCompatibility from 1.8 to 11 in build.gradle (commit
ebe7297 by @Naenyn, 2026-03-05) which means deployers on Java 8
can no longer run this release. That impact never made it into
CHANGES.md when v5.17.2 shipped.

Goal: backfill the v5.17.2 entry so deployers reading CHANGES.md know
they need a JVM upgrade before consuming v5.17.2 or later.

Changes:
- docs/CHANGES.md: insert a `## v5.17.2` block between v5.17.3 and
  v5.15.2 calling out the Java 11 floor.

Notes: chose to add this to the existing v5.17.3 docs PR rather than
spinning a separate one — they're both backfill work for the same
file and ship together cleanly.