Play Framework

refactor: remove play.http2.enabled flag — ALPN h2 always on with HTTPS (release 1.12.20)

PF-58 introduced play.http2.enabled as an opt-in safety net while we
built confidence in the h2 path. PF-66 unified PEM and JKS through one
Netty SslContext. PF-67 wired a CLI to manage HTTPS. With those in
place, the flag adds no value: ALPN gracefully degrades — clients that
don't speak h2 negotiate http/1.1 cleanly via SelectorFailureBehavior
.NO_ADVERTISE — so "ALPN off" is strictly worse for h2 clients without
helping h1.1 clients. There's no scenario where toggling ALPN at the
SslContext level is the right move.

Drop the flag. ALPN is always advertised when HTTPS is configured.

Removed:
- SslHttpServerPipelineFactory.isHttp2Enabled()
- The boolean withAlpn parameter on buildSslContext() and buildSslHandler()
- The if (http2Enabled) branch in initChannel — now unconditionally
  installs the ALPN handler
- The conditional ApplicationProtocolConfig in buildSslContext — now
  always built
- play.http2.enabled writes from enable-https (no longer needed)
- play.http2.enabled comment-out from disable-https (no longer
  needed; the line was never written by enable-https)
- _is_active_value helper in https.py (only consumer was the flag check)
- buildSslContextFromJksWithoutAlpnSucceeds test (no "without ALPN"
  shape to test anymore)
- Three flag-parsing tests in SslHttpServerPipelineFactoryAlpnTest
- %test.play.http2.enabled=true from the integration testapp conf

Renamed:
- buildSslContextFromJksWithAlpnAdvertisesH2ThenHttp1 →
  buildSslContextFromJksAdvertisesH2ThenHttp1 (no other shape exists)

Doc updates:
- cmd-enable-https.txt drops the play.http2.enabled step (now 3 steps,
  not 4); explicitly notes ALPN is always on at framework level
- cmd-disable-https.txt drops the play.http2.enabled comment-out
- dependencies.yml comment for netty-codec-http2 updated to reflect
  always-on activation

The CLI's user-facing contract is now strictly comment/uncomment-only
on https.port — no hidden flag to remember. Same UX whether you use
the CLI or hand-edit application.conf.

End-to-end verified on a fresh app:
  $ play enable-https
  ~ HTTP enabled on port 9000.
  ~ HTTPS enabled on port 9443 (HTTP/2 via ALPN).
  $ grep play.http2.enabled conf/application.conf  → (no output)
  $ play start
  $ curl -kvs --http2 https://localhost:9443/
    * ALPN: server accepted h2

  $ play disable-https
  ~ HTTPS disabled.
  $ grep -n https conf/application.conf
    287:# https.port=9443
  $ grep play.http2 conf/application.conf  → (no output)

Behavior change for any existing app with explicit play.http2.enabled=
false: after this commit those apps will negotiate h2 with capable
clients. ALPN's graceful fallback means h1.1 clients are unaffected,
so the only observable difference is that h2 clients now actually get
h2 (which is what they wanted).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>