[v3] Support CPU without AVX/AVX2

[g1n93r]

Use case:
We deploy InfluxDB at the edge on low-power Intel boxes (e.g., Gemini Lake J4125) for building-management/industrial IoT. These CPUs are still very common in fanless gateways and mini-PCs, but they do NOT support AVX/AVX2. Today InfluxDB 2.x runs fine on them. We'd like to upgrade sites to InfluxDB 3, but the official v3 binaries require Haswell-class features (AVX2/FMA/BMI2), causing immediate crashes on these devices.

Impact: dozens to hundreds of on-prem servers across multiple customers; hardware refresh is costly and wasteful when the workload itself is modest.

Proposal:

1. Publish an additional x86-64-v2 build (no AVX/AVX2 requirement) of InfluxDB IOx (Docker image + tarball), or
2. Add runtime CPU feature detection with a clear error message that explains the minimum required features (e.g., “This build requires AVX2/FMA/BMI2; your CPU lacks AVX2”), and
3. Document CPU requirements prominently in the release notes and Docker Hub README.

Nice-to-have: a CI matrix producing both x86-64-v3 (current Haswell/AVX2) and x86-64-v2 artifacts, with distinct Docker tags like influxdb3:latest (v3) and influxdb3:x86-64-v2 (legacy/compat).

Current behaviour:
On CPUs without AVX/AVX2 (e.g., Intel J4125 Gemini Lake), the InfluxDB 3 process exits immediately with code 132 (SIGILL/illegal instruction) when launched (binary or container). There is no helpful log output explaining the CPU feature mismatch, which makes troubleshooting harder for operators.

Desired behaviour:

• Either an official compatibility build that runs on x86-64-v2 (no AVX2), accepting reduced performance but enabling upgrades on common edge hardware,
• Or at minimum, a graceful preflight check that detects missing CPU features at startup and logs a clear, actionable message before exiting.

Alternatives considered:

• Staying on InfluxDB 2.x on these machines (works, but we lose v3 benefits and must maintain mixed versions).
• Replacing edge hardware (costly, slow to roll out, increases e-waste for modest telemetry workloads).
• Maintaining our own custom builds targeting x86-64-v2 (possible, but fragments the ecosystem and complicates support/updates).

Thanks for considering a compat target and/or clearer startup diagnostics — this would unlock upgrades for a large class of real-world edge devices.