feat(profiling): Support inbound filters for profiles

[Zylphrex]

This adds support for inbound filters on profile types specifically allowing to filter profiles based on releases.

[jjbayer]

@Zylphrex could you add an integration test for this? Something along the lines of

relay/tests/integration/test_filters.py

Lines 287 to 309 in 5b0798d

	def test_client_ip_filters_are_applied(
	mini_sentry,
	relay,
	):
	"""
	Test that relay normalizes messages when processing is enabled and sends them via Kafka queues
	"""
	relay = relay(mini_sentry)
	project_id = 42
	project_config = mini_sentry.add_full_project_config(project_id)
	filter_settings = project_config["config"]["filterSettings"]
	filter_settings["clientIps"] = {"blacklistedIps": ["1.2.3.0/24"]}
	event = {"message": "foo"}
	relay.send_event(project_id, event, headers={"X-Forwarded-For": "1.2.3.4"})
	report = mini_sentry.get_client_report()
	assert report["filtered_events"] == [
	{"reason": "ip-address", "category": "error", "quantity": 1}
	]
	assert mini_sentry.captured_events.empty()

(testing with relay and mini_sentry should be enough, no need to spawn relay_with_processing).

Rest of the PR looks good to me!

[jjbayer]

Will we filter on more fields in the future? Users might be surprised when they configure a release filter, see that it works, and then try the same for ip_addr and it fails.

[Zylphrex]

For ip_addr, I see that it's pulled from the user for other event types. Meaning for a backend event, it'll use the frontend user IP. Is this a strict requirement? Because for continuous profiles, we can only send the ip of the server in some cases.

[jjbayer]

So far the filter has only been applied to the end-user IP like you said, so in this case I would leave it empty (None) for continuous profiles.

[loewenheim]

Not directly related to this PR, but it might be worth defaulting these methods in the trait.