[18.0][FIX] auditlog: prevent recursion on re-entrant write from compute/inverse

[midhlaj-nk]

Problem

When an auditlog rule is active for a model that has compute or inverse methods that trigger write() on the same model (e.g. account.account with _compute_code / _inverse_code), a RecursionError: maximum recursion depth exceeded is raised.

Root cause: write_full and write_fast set auditlog_disabled=True via self = self.with_context(auditlog_disabled=True), which only modifies the local self. Compute/inverse methods triggered by the original write call write() on the model class using their own self, which does not carry the modified context. This causes the patched write_full/write_fast to re-enter indefinitely.

Closes #3512

Solution

Add an early-exit guard as the first statement of both write_full and write_fast:

if self.env.context.get("auditlog_disabled"):
    return write_full.origin(self, vals, **kwargs)

When a re-entrant write call arrives (already carrying auditlog_disabled=True), the closure immediately delegates to the origin and returns — no logging, no further recursion.

Tests

Added TestAuditlogRecursion with three test cases:

• test_no_recursion_write_full_reentrant: company write syncs address to child partner (both audited, full log) — verifies no RecursionError
• test_no_recursion_write_fast_reentrant: same scenario with fast log
• test_write_full_guard_skips_logging: write with auditlog_disabled=True in context produces no log entry — verifies guard path is taken

[StefanRijnhart]

Thanks for having a go at this. The added test fails, but also I fear this solution might undermine the situation in which the write of a tracked model triggers a write on another tracked model. The changes on the latter model might not be recorded due to the application of the context key. Furthermore, the semantics of this particular context key, which was somewhat unfortunately named I believe was to disable read logging in particular. All of this has been digested on #3646 which I think is in a pretty good shape now. Maybe you can test and review that version, and maybe try to cherry-pick its solution for 18.0?