fix(jdbc): unique HikariCP pool name per SlickDatabase provider (#13)

[fupelaqu]

What & why

Fixes the HikariCP pool-name collision described in #13.

Every SlickDatabase provider (JdbcSchema, JdbcStateProvider,
ColumnMappedJdbcStateProvider, JdbcOffsetProvider, …) builds its own
non-shared HikariCP pool. akka-persistence-jdbc 5.0.4 builds each via
Database.forConfig("slick.db", config), and Slick's HikariCPJdbcDataSource
defaults poolName to the config path → every pool is named slick.db.

In a single JVM this yields multiple distinct pools sharing one name. As soon as
a consumer sets slick.db.registerMbeans = true, only the first pool registers
com.zaxxer.hikari:type=Pool (slick.db); the rest fail with
JMX name (slick.db) is already registered. The same name clash breaks
HikariCP's native Prometheus tracker (collectors are keyed by pool name).

Approach

Approach #1 (unique pool names) from the issue — lowest blast radius, no
lifecycle change.

In SlickDatabase, inject a unique slick.db.poolName into the config before
handing it to SlickExtension(system).database(config):

• Name format slick.db-<providerClass>-<counter> (JVM AtomicLong counter
  guarantees uniqueness even for multiple instances of the same class).
• Only injected when a slick.db block is present and no poolName was set
  explicitly (an explicit slick.db.poolName is respected; configs without a
  slick.db block pass through unchanged).
• Names are sanitized to [A-Za-z0-9._-] so they are valid as a JMX
  ObjectName value and as a Prometheus label.
• getClass.getSimpleName is guarded with Try (avoids the JDK 8
  InternalError: Malformed class name on synthetic/anonymous classes).

The shared journal/snapshot/read-journal pool (use-shared-db) is built by akka
itself and keeps its own default name — out of scope, and it does not collide
with the new slick.db-… names.

Tests

New SlickDatabasePoolNameSpec (H2, no Docker):

• distinct HikariCP pool name per provider;
• an explicitly configured slick.db.poolName is left untouched;
• with registerMbeans = true, two pools register distinct JMX MBeans.

These assertions fail without the fix (both pools would be named slick.db).

Verification

• jdbc/scalafmtCheck ✅
• + jdbc/compile (Scala 2.12.20 + 2.13.16) ✅
• new spec + existing H2 specs (23 tests) ✅

Acceptance (issue #13)

• With registerMbeans=true, no already registered ERRORs; one MBean per
  live pool with distinct names.

Addresses #13. (Left open intentionally — not auto-closing via keyword.)

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.34%. Comparing base (a59c322) to head (526369f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #14      +/-   ##
==========================================
+ Coverage   61.05%   61.34%   +0.29%     
==========================================
  Files          95       95              
  Lines        1854     1868      +14     
==========================================
+ Hits         1132     1146      +14     
  Misses        722      722              

Flag	Coverage Δ
unittests	61.34% <100.00%> (+0.29%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.