neorados: Go through linger_cancel on `io_context` shutdown

Rather than just dropping the reference, clean up the linger operation
properly within Objecter. Also, clear out handlers before
relinquishing reference to avoid use-after-free.

Signed-off-by: Adam C. Emerson <aemerson@redhat.com>

Merge pull request #66539 from ceph/GHSA-8v8w-v8xg-79rf

.github: Harden workflow against arbritrary code injection

.github: Harden workflow against arbritrary code injection

See https://github.com/tj-actions/branch-names/security/advisories/GHSA-8v8w-v8xg-79rf

Signed-off-by: David Galloway <david.galloway@ibm.com>

Merge pull request #66505 from tchaikov/mgr-dont-fail-sans-notify-types

mgr/PyModule: clear Python exception when NOTIFY_TYPES is missing

Reviewed-by: John Mulligan <jmulligan@redhat.com>

Merge pull request #57263 from mchangir/mgr-snap_schedule-restrict-retention-period-multiplier-set

mgr/snap_schedule: restrict retention period multipliers set

Reviewed-by: Venky Shankar <vshankar@redhat.com>

mgr/PyModule: clear Python exception when NOTIFY_TYPES is missing

Commit 4589c4d8ac5 ("mgr: do not require NOTIFY_TYPES in python modules")
changed load_notify_types() to treat missing NOTIFY_TYPES as non-fatal,
but failed to clear the Python exception state set by PyObject_GetAttrString().

When PyObject_GetAttrString() fails to find an attribute, it:
1. Returns nullptr
2. Sets AttributeError in the interpreter's exception state

The exception state persists across subsequent Python C API calls until
explicitly cleared. This causes unrelated operations to fail with misleading
error messages.

Bug Manifestation:
------------------
In PyModule::load() (line 292), the call sequence is:

1. load_subclass_of("MgrModule", &pClass) - succeeds
2. load_notify_types() - sets AttributeError but returns 0 (success)
3. load_subclass_of("MgrStandbyModule", &pStandbyClass) - FAILS

The failure occurs because PyImport_ImportModule() at line 658 checks
PyErr_Occurred() before operating. When it detects the pending AttributeError
from step 2, it refuses to import and returns NULL immediately.

This causes load_subclass_of() to report:
```
  1 mgr[py] Loading python module 'balancer'
 -1 mgr[py] Module balancer has missing NOTIFY_TYPES member
 -1 mgr[py] Module not found: 'mgr_module'
 -1 mgr[py] AttributeError: type object 'Module' has no attribute 'NOTIFY_TYPES'
```

This error is misleading - mgr_module exists and is importable, but the
import fails due to the uncleared exception from an unrelated operation.

Without this fix, modules without NOTIFY_TYPES may fail to load their
standby class, or cause subsequent module loads to fail entirely with
confusing error messages pointing to the wrong module.

Fix:
----
This patch follows Python's EAFP (Easier to Ask for Forgiveness than
Permission) philosophy by attempting the attribute access and handling the
expected AttributeError, rather than checking preconditions with
PyObject_HasAttrString() (LBYL approach). The EAFP approach:

- Is more pythonic and idiomatic
- Requires only one API call instead of two (more efficient)
- Properly distinguishes expected errors (AttributeError) from unexpected
  errors (e.g., interpreter shutdown, memory errors)
- Handles unexpected errors appropriately by reporting and returning -EINVAL

Implementation:
- Use PyErr_ExceptionMatches() to check for expected AttributeError
- Clear expected exception with PyErr_Clear()
- Report unexpected exceptions via handle_pyerror()

Refs: 4589c4d8ac5 ("mgr: do not require NOTIFY_TYPES in python modules")
Refs: https://tracker.ceph.com/issues/55835
Fixes: https://tracker.ceph.com/issues/70789
Signed-off-by: Kefu Chai <k.chai@proxmox.com>

Merge pull request #65274 from ifed01/wip-ifed-more-max-lat

os/bluestore: track max latencies for key bluestore/bluefs perf counters

Reviewed-by: Adam Kupczyk <akupczyk@ibm.com>