feat(inbound filters): Enable filtering sessions

[loewenheim]

This enables filtering for SessionUpdate and SessionAggregate items. In the course of this, it also

• adds Filterable and Getter implementations to SessionUpdate and SessionAggregates;
• introduces a SessionProcessingConfig struct to bundle all the auxiliary data needed in process_session and process_session_aggregates (modeled on ReplayProcessingConfig);
• slightly refactors how session processing is called.

Aside from this not having tests, my main open questions are around the Getter impls. To wit:

• Is there some sort of schema for what the path segments should be called? Is it just the names of the fields they return? Does anything break if they aren't chosen correctly?
• Are the names for the "roots" of the two types appropriate? Should they be closer to the actual type names ("session_update"/"session_aggregates")?
• Are there any fields I made addressable that shouldn't be?
• In practical terms, do the Getter impls change anything about the way filtering works? I believe Filterable already returns the fields we actually care about.

Closes RELAY-41.

[loewenheim]

I've now reduced the Getter impl for SessionUpdate to the bare minimum (release, environment, ip_addr, user_agent).

[Dav1dde]

In practical terms, do the Getter impls change anything about the way filtering works? I believe Filterable already returns the fields we actually care about.

That's the question, do you need even any fields filterable (aka a Getter impl that can get anything)?

Is there some sort of schema for what the path segments should be called? Is it just the names of the fields they return? Does anything break if they aren't chosen correctly?

Usually the JSON path of the fields, since sessions are more like metrics, this may not make sense.

[loewenheim]

@Dav1dde I added a paragraph about client and user IPs to the should_filter docstring, lmk if it sounds ok.