sdk: Enable configurable buffer exhausted policy for TrackEvent

[bsarden]

TrackEvent inherits from DataSource which defaults kBufferExhaustedPolicyConfigurable to false. This means the buffer exhausted policy (drop vs stall) is fixed at compile time and cannot be changed via the trace config at runtime.

Setting kBufferExhaustedPolicyConfigurable to true on TrackEventDataSource allows trace configs to override the default kDrop policy with kStall on a per-session basis. This is useful for scenarios where completeness of trace data is more important than avoiding writer stalls, such as deterministic testing or targeted traces where dropping events would invalidate results.

Without this change, users who need stall-on-full behavior for TrackEvent must create a custom data source wrapper just to flip this flag, which might be unnecessary boilerplate. The redundancy comes up when having to re-define all the TRACE_ macros to use the custom data source wrapper.

I haven't found a reason for why TrackEvent buf exhausted policy is non-configurable upstream.
There might be a valid reason for this.
If so, what would the recommendation be for achieving 'lossless TrackEventDataSource' behavior?

cc: @dreveman

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[LalitMaganti]

I think the reason for this behaviour is pure oversight. Configurable buffer exhausted modes were only introduced signifcantly after track event and I think we never thought about retroactively applying that to TrackEvent.

@primiano @sashwinbalaji would be the right people to confirm the above.

[primiano]

So I did some digging in #1312 and the internal bug b/384007571

I think this feature was introduced to allow SDK users that implement data sources to make it configurable by calling PerfettoDsSetBufferExhaustedPolicyConfigurable(true)

I think back then nobody thought about track event, it was focused only on the DS layer.

Now there is a legitimate question that is: should TrackEvent itself be configurable?

I think depends on whether you want:

A) TrackEvent in an app you control to be configurable: I'd be absolutely positive about this (But shoudl be done in a different way than this PR)

B) TrackEvent to be always configurable. I'd be a bit more careful here. My problem here is the fact that trak event is used in key system services (e.g system_server). Making this universally configurable (incl system_server) means making it so that if somebody copy/pastes the wrong flag into the config without knowing what they are doing, they will cause a device soft-reboot, which is unideal

So if you want to send out a PR for A, i'm more then happy to review, but needs to be something that a client of TrackEvent calls explicitly when initializing.