Refactor InfluxQL TSDB client to reduce global config coupling and enable InfluxDB 2.x compatibility backend

[mahmoudnasser1561]

Is your feature request related to a problem? Please describe.

The current InfluxDB TSDB client is tightly coupled to the global TIMESERIES_DB configuration dict defined at import-time in openwisp_monitoring/db/backends/init.py. This makes it difficult to add new TSDB backends (e.g., InfluxDB 2.x in InfluxQL compatibility mode) without duplicating the client implementation or relying on mutating global state, which is harder to test and maintain.

this makes adding other specific customized backends later difficult, hard to test and maintain.

Describe the solution you'd like

Extract a shared InfluxQL-compatible base client (e.g., BaseInfluxDatabaseClient in openwisp_monitoring/db/backends/influx_base.py) containing the existing InfluxQL logic. Refactor the current InfluxDB backend client (openwisp_monitoring/db/backends/influxdb/client.py) into a thin subclass. The base client should remain backward-compatible by defaulting to TIMESERIES_DB, but also support optional instance-level overrides via

__init__(db_name=None, options=None, **config)

to reduce global coupling and enable future backends to reuse the implementation cleanly.

Acceptance Criteria

• No behavior changes; existing test suite passes
• ./run-qa-checks passes
• BaseInfluxDatabaseClient is introduced and contains all existing InfluxQL client functionality.
• InfluxDB backend client becomes a thin subclass of the base.
• No runtime behavior changes for existing users (backward-compatible).

Describe alternatives you've considered

• Duplicating the existing InfluxDB client into a new influxdb2 backend directory and maintaining two similar codepaths (high duplication and maintenance cost).

• Keeping the current client unchanged and building InfluxDB2 support by mutating/overriding the global TIMESERIES_DB at runtime (harder to test, less explicit, riskier).

• Creating a completely separate InfluxDB2 client using Flux and a different Python library (larger scope and would not reuse the existing InfluxQL query logic).

Additional context

• This refactor is intended as a paving change for clean InfluxDB 2.x backend integration without duplication.