drivers/sensors/sensor: fix poll()/read() for fetch()-only sensors

[FelipeMdeO]

Summary

A fetch()-only lower half reads the device on demand, so it's always
ready, nothing to wait for. The upper half didn't reflect that:
sensor_poll() only reported POLLIN when opened O_NONBLOCK, and a
blocking read() waited on buffersem, which only a driver-owned
interrupt (notify_event) posts. A fetch()-only sensor with no
interrupt therefore never satisfied poll()/read() at all — e.g.
in-tree nucleo-h563zi:dts hangs on a blocking read() today.
Applications worked around this with O_NONBLOCK (apache/nuttx-apps#3686);
this PR fixes it at the root instead, per reviewer feedback there.

Three commits:

1. l3gd20 → push-only. Its old BUFFER_SIZE == 0 mode kept fetch()
   set while also driving notify_event from the data-ready interrupt,
   and that combination was itself buggy, not just inconsistent:
   sensor_poll()'s fetch-only branch reported POLLIN whenever the
   descriptor was O_NONBLOCK, regardless of whether the interrupt had
   actually fired, so a multi-descriptor poll() loop could read stale
   or duplicate data off the l3gd20 while correctly waiting on other
   sensors. Push-only fixes that, and generalizes to every
   interrupt-driven sensor in the tree: the interrupt handler reads the
   sample and calls push_event(), landing it in the upper half's
   circular buffer and waking any poller through sensor_pollnotify().
   POLLIN is then reported only when sensor_is_updated() sees a
   generation the caller hasn't consumed yet — acquisition (the
   interrupt reading the chip) and delivery (the app's read()) are
   decoupled and correctly synchronized, instead of read() racing the
   next interrupt. read() never touches the bus at that point, it just
   copies out of the buffer. This is the existing, already-correct model
   for every other push sensor in tree; l3gd20 was the one exception.
2. sensor_poll()/sensor_read() always ready for fetch()-only.
   The actual fix. notify_event becomes dead code for fetch()-only
   lower halves as a result; left the API in place, open to deprecating
   it in a follow-up.
3. Pace POLLIN at the requested interval. Without it, a rate
   request (-r) got no help from poll(), and apps sleeping it out
   themselves serialize across multiple topics (three at 10 Hz → 3.3 Hz
   each). A per-subscriber work_s timer, armed in sensor_poll(),
   paces each one at its own interval — the fetch() counterpart of what
   sensor_is_updated() already does for push. Falls back to
   always-ready without CONFIG_SCHED_LPWORK.

Impact

Any fetch()-only uORB sensor (on-demand I2C/SPI, no interrupt) now
works with poll()/read() without the app forcing O_NONBLOCK. Every
interrupt-driven sensor, including l3gd20 after commit 1, keeps blocking
correctly until real new data arrives — nothing about push semantics
changes for them, verified both by code and on hardware (Testing).

Testing

Host: Ubuntu 24.04.3 LTS. checkpatch.sh (style + -m commit messages)
clean on all 3 commits.

Compiles clean on 3 architectures touching the changed
drivers/sensors/sensor.c: xtensa-esp-elf-gcc 14.2.0 (esp32s3-devkit),
arm-none-eabi-gcc 13.2.1 (stm32f4discovery), and sim (x86_64,
UORB_LISTENER + CONFIG_SCHED_LPWORK).

Fetch-only sensor on hardware — ESP32-S3-DevKitC + MPU6050 (GY-521)
on I2C0, fetch()-only with no interrupt line, no O_NONBLOCK anywhere
in the unmodified apps/system/uorb/listener.c:

nsh> uorb_listener -n 5 sensor_accel0
Monitor objects num:1
object_name:sensor_accel, object_instance:0
sensor_accel(now:37860000):timestamp:37860000,x:-0.205901,y:-0.122104,z:10.323798,temperature:23.824116
sensor_accel(now:37860000):timestamp:37860000,x:-0.205901,y:-0.122104,z:10.323798,temperature:23.777058
sensor_accel(now:37860000):timestamp:37860000,x:-0.205901,y:-0.122104,z:10.323798,temperature:23.730000
sensor_accel(now:37860000):timestamp:37860000,x:-0.205901,y:-0.122104,z:10.323798,temperature:23.918234
sensor_accel(now:37860000):timestamp:37860000,x:-0.131681,y:-0.134075,z:10.299856,temperature:23.824116
Object name:sensor_accel0, received:5
Total number of received Message:5/5

Per-subscriber pacing, same hardware: two uorb_listener processes
on sensor_accel0 at once, -r 20 and -r 5. Samples landed ~60ms and
~210ms apart respectively — each subscriber paced at its own rate, not
the minimum across both (the failure mode of an earlier per-device-timer
prototype).

Teardown under stress: 8 rounds of uorb_listener -r 5 sensor_accel0 &
followed by SIGINT mid-poll. ps afterward shows no leaked task and no
stuck lpwork item; the sensor still answers normally right after.

Push sensor on hardware — STM32F4Discovery onboard accelerometer via
CONFIG_SENSORS_LIS3DSH_UORB: turned out to be an LIS302DL (older board
revision, confirmed by WHO_AM_I=0x3b vs LIS3DSH's 0x3f), a
pre-existing hardware mismatch unrelated to this change, so no live data
from this one. Push path correctness instead verified by inspection: the
else branch in sensor_read()/sensor_poll() that push sensors take
is untouched by this series.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

should we avoid the work queue? the benefit from fetch is avoiding the work or thread.