Django middleware filtering settings

[lrafeei]

This PR adds three settings related to Django middleware instrumentation:

instrumentation.middleware.django.enabled
instrumentation.middleware.django.exclude
instrumentation.middleware.django.include

Where the exclude/include settings follow similar rules to attribute exclude/include: https://docs.newrelic.com/docs/apm/agents/python-agent/attributes/enabling-disabling-attributes-python/#rule-specific-wins

1. If instrumentation.middleware.django.enabled is disabled, no middlewares are recorded, despite what may be in the include list
2. Exclude always supersedes include
3. Middleware names are case sensitive
4. * denotes a wildcard. NOTE: This will not work as a pure wildcard, as it will only work at the end of a name and not in the middle or beginning.
5. Most specific setting for a middleware name takes priority. That is, if exclude has middleware names using a wildcard but include does not and include's middleware name is within the set of exclude's wildcard middleware names, the middleware name in include will take precedence.
   i.e.
   Middleware seen in application: "foo", "bar", "baz"
   instrumentation.middleware.django.enabled = True
   instrumentation.middleware.django.exclude = ["ba*"]
   instrumentation.middleware.django.include = ["baz"]
   Middleware that is included in instrumentation: "foo", "baz"
   Middleware that is excluded in instrumentation: "bar"

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ ACTION	actionlint	6		0	0	0.74s
✅ MARKDOWN	markdownlint	7	0	0	0	1.26s
✅ MARKDOWN	markdown-link-check	7		0	0	21.49s
✅ PYTHON	ruff	936	0	0	0	0.91s
✅ PYTHON	ruff-format	936	0	0	0	0.36s
✅ YAML	prettier	13	0	0	0	1.38s
✅ YAML	v8r	13		0	0	6.39s
✅ YAML	yamllint	13		0	0	0.61s

See detailed report in MegaLinter reports

[codecov-commenter]

Codecov Report

❌ Patch coverage is 90.90909% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.42%. Comparing base (d1bcc83) to head (1029ae2).

Files with missing lines	Patch %	Lines
newrelic/hooks/framework_django.py	91.83%	2 Missing and 2 partials ⚠️
newrelic/core/config.py	83.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1444      +/-   ##
==========================================
+ Coverage   81.33%   81.42%   +0.09%     
==========================================
  Files         209      209              
  Lines       23650    23709      +59     
  Branches     3724     3740      +16     
==========================================
+ Hits        19236    19306      +70     
+ Misses       3153     3146       -7     
+ Partials     1261     1257       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hmstepanek]

Posting a partial review-I need to look at the tests and the include/exclude implementation a little bit deeper.

[hmstepanek]

Can we just point at this method rather than re-creating the exact same implementation again: _parse_attributes? Maybe just rename it to be generic or accept an additional argument for the log message.

[hmstepanek]

Cache the value so we aren't computing it twice.

Suggested change

	if not include_logic(callable_name, name):
	include = include_logic(callable_name, name)
	if not include:
	return False
	else:
	deny |= include

[hmstepanek]

My brain is fried from trying to understand this...I'll come back to this later and hopefully it will make more sense. In theory I see what you are trying to do here but my brain is not following all of these implementation details.

[lrafeei]

Fair--it gets a bit dicey. A lot of the complexity in this logic comes from attempting to sort out a case like this one:

Middleware = django.middleware.common:CommonMiddleware, django.middleware.csrf:CsrfViewMiddleware
exclude = ["django.middleware.c*"],
include = ["django.middleware.", "django.middleware.co"]

The django.middleware.* in the include list is effectively a no op. However, in the case where a user has this scenario, this should still filter correctly (based on the more specific include statement, django.middleware.co*, relative to the exclude statement django.middleware.c*

[hmstepanek]

Ok I mainly just want some more thorough tests for the filtering-otherwise this looks good.

[hmstepanek]

Can we get some more tests here:

• there aren't *'d paths.
• there is only an exclude rule
• there is only an include rule
• there are no dots in the paths
• there are only dots in the include path
• there are only dots in the exclude path
• there is a path with a dot (no *) and a path with no dots and only a *
• case sensitive test
  There's probably some additional cases I'm not thinking of?

I want to be really thorough when we test these cause there's a lot of complex logic there and I don't want to miss some corner case bug in the implementation. (I don't see any but it might be hard to catch without thorough testing.)