Handling DB connection reset

### Current Behavior

With connection pool disable:

- Several connections are kept opened in idle
- No keep alive is performed, nor configurable in alpine
- Connection reset is not detected before application tries to access it
- Application raises an exception when the condition occurs
- User is forced to retry until eventually all IDLE connections have been tried an new one have spawn

REM:
- Turning connection pool on is just making the problem worse and more difficult to understand. Depending on the configuration, I get either: a) massive connection leakage or b) Hikari refusing to create new connections. I have not found a way to avoid periodic backend restart with connection pool enabled.
- After some hesitation, I report as an improvement because dependency track clearly lack proper options at this stage to deal with DB connection reset. However any user facing the issue will see it as a bug.

### Proposed Behavior

I expect either:

A. Add optional keep alive, obviously discarding connection in case of issue/reset
B. Implement reconnect and retry in case `java.net.SocketException: Connection reset` is detected during a JDO call
C. Close connection after some configurable time in IDLE, that is no connection remains in IDLE forever (which does not work even in pool mode)
D. (Least resort) Close connection immediately after usage / Get always a fresh new connection

REM:
- DataNucleus seems to offer options for A and C but Alpine framework do not expose them.
- Connection pool through HikariCP seems to leverage some of those options but I cannot make them work properly either. See remarks in current behavior.

### Checklist

- [X] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [X] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested