fix(django): trace cache.add operations

[immanuwell]

Refs #6402

cache.add() was a blind spot. cache.set() emitted cache.put, cache.add() emitted nothing. kinda odd for a normal Django cache write path.

Repro

from django.core.cache import cache
import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration

sentry_sdk.init(
    integrations=[DjangoIntegration(cache_spans=True)],
    traces_sample_rate=1.0,
)

with sentry_sdk.start_transaction(name="t", op="test"):
    cache.add("k", "value")

Before this patch: no cache span.
After this patch: one cache.put span for cache.add().

What changed

• instrument cache.add()
• treat it as cache.put
• add a regression test for static + stream mode

Tested

• tox -e py3.12-django-v4.2.30 -- -k test_cache_spans_add

I also checked a wider Django cache test slice, but this env doesnt have the repo's local Postgres test service, so the db-marked Django tests bail early.

[ericapisani]

Thanks for opening this PR! These changes are overall looking good, just need to update something in the span streaming test before we look to get it across the finish line.

[ericapisani]

In the context of span streaming, we no longer have the concept of a transaction, we instead have a segment.

Because of that, we shouldn't be invoking this method, but if we need to create a span to attach the generated cache span to, use with sentry_sdk.traces.start_span(...) instead.

The assertions from lines 575 to 579 will likely need to be updated as a result, as there will be another span caught by the capture_items line above, so the index value used will change.

[alexander-alderman-webb]

Yes, just adapt the test to follow the existing pattern in the same file @immanuwell

[alexander-alderman-webb]

Please merge master into your branch as well to resolve unrelated CI failures.