Make do interventions shared variables by default

[ricardoV94]

This behavior should be more intuitive, since do interventions create Data containers, and users expect those to be mutable by default. This also alleviates some issues related to sample_posterior_predictive that currently does not look for sources of mutability on constants:

Closes #6977 (I tested the MWE locally)
Related to #7069

We could consider something similar for pm.observe but that doesn't create data containers at all right now, so it's a tad less relevant and would require more changes.

---

📚 Documentation preview 📚: https://pymc--7596.org.readthedocs.build/en/7596/

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.67%. Comparing base (62335ac) to head (63cf0e8).
Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7596   +/-   ##
=======================================
  Coverage   92.67%   92.67%           
=======================================
  Files         107      107           
  Lines       18313    18317    +4     
=======================================
+ Hits        16971    16975    +4     
  Misses       1342     1342           

Files with missing lines	Coverage Δ
pymc/model/transform/conditioning.py	95.91% <100.00%> (+0.17%)	⬆️

[drbenvincent]

Might not be strictly required for this issue, but would solve one of my recurring concerns... but could potentially add a test for something like

with pm.Model() as model:
    a = pm.Normal("a")
    b = pm.Deterministic("b", a*2)
    c = pm.Normal("c", b/2)

then intervene on a with pm.do, resample with pm.sample_posterior_predictive, and check that the values of c have changed. Just an idea, might be not fully formed.

[lucianopaz]

LGTM

[ricardoV94]

@drbenvincent I am a bit conflicted. I do want to test that as a user, but not as part of the codebase as it's covering something that's orthogonal to it: #6876

This PR is not a solution to that problem, but sidesteps it in this specific case. Even if we didn't have that problem we would still want this PR so you can use set_data if the users wished to.

[ricardoV94]

Since I'm conflicted I'll add it @drbenvincent . It does test the behavior we want in the end

[drbenvincent]

Sure - totally fine for you to ignore my suggestion. There are a bunch of PR's which are all closely related and I don't have enough knowledge to know which exact PR would be relevant for a user-facing test like this. Feel free to ignore. Can possibly add a test along these lines to one of the other PR's potentially.

[ricardoV94]

Added a test @drbenvincent

[drbenvincent]

new test looks cool