Keep access tokens and raw PII out of the Messenger transport

[loevgaard]

Fixes #17

Stacked on #48.

Problem

SendEvent carried the whole Event object. At dispatch time that object holds the pixels including their access tokens, and the raw email addresses, phone numbers, names and dates of birth the application attached, because normalisation and hashing only happen inside Parameters::getPayload(), which the SDK calls later in the handler.

Routing the command to a transport, which is the recommended setup, therefore wrote all of that into the transport's storage, into the failure transport when it failed, and into anything that dumps messages such as messenger:failed:show. Failure transports are often kept indefinitely, so it was a retention problem as well as a secrets problem.

Change

SendEvent now carries the finished payload:

new SendEvent($eventName, $eventId, $payload, $pixelIds, $testEventCode);

built with SendEvent::fromEvent($event). The payload is produced by the SDK at dispatch time, so it is already normalised and hashed, and only pixel ids travel.

Access tokens are resolved when the event is sent, through a new AccessTokenResolverInterface. ConfigurationBasedAccessTokenResolver reads them from the pixels configuration, which is request independent and therefore safe to run in a worker. Applications with their own PixelProviderInterface alias the resolver too, as documented in README.md and UPGRADE.md.

PreparedEvent (internal) hands the precomputed payload back to ClientInterface::sendEvent(), which takes an Event. It extends the SDK's Event, which is explicitly documented as non-final for this kind of extension, and overrides getPayload().

A welcome side effect: everything in the message is now a scalar or an array, so it also survives the Symfony serializer rather than requiring the PHP one.

Tests

The important one serialises a message built from an event carrying an access token, an email address, a phone number and a first name, then asserts none of those four strings appear in the serialised output, while the payload holds the SHA-256 of the email. Plus three tests for the resolver, including the fact that numeric pixel ids become integer array keys in PHP, and three for the rewritten handler.

Review findings, folded in

• Messages from 0.1.x still in a transport. Their body has the old $event shape. Messenger's PhpSerializer decodes it into the current class with every property uninitialised (the class exists, and deprecations are exempt from decoding failures), the handler threw a plain Error, and Messenger retried it three times before parking it — body, token and raw PII included. The handler now detects the old shape and throws UnrecoverableMessageHandlingException, so it goes to the failure transport once, with a reason. UPGRADE.md tells you to drain the transport on the old release before deploying.
• A custom PixelProviderInterface without a resolver lost all server-side tracking silently. The old handler honoured tokens on the Pixel objects; this PR strips them by design. Every event then logged one warning per pixel and returned — and a stock production Monolog setup buffers warnings away. When no pixel has a token, the handler now logs at error, naming the resolver. The three places in the docs that recommend aliasing the provider now say to alias the resolver too.
• ConfigurationBasedAccessTokenResolver is added to the integration test's registry of conditional server-side services, so its presence and absence are asserted like the other two.
• From the second pass, after the rate limit: a pixel listed twice by a provider now travels once, since the client posts once per pixel; and configuring the same pixel id twice is rejected at compile time, because the token is now looked up by id and a second entry would silently win. Also confirmed, with no change needed: a payload that fails to build at raise time is caught by the dispatch subscriber and logged rather than becoming a poison message in the worker; and getPayload()'s browser context is only ever requested from userData and customData, never from the event.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.06%. Comparing base (ee105bc) to head (861c973).

Additional details and impacted files

@@             Coverage Diff              @@
##             master      #49      +/-   ##
============================================
+ Coverage     97.95%   98.06%   +0.11%     
- Complexity      151      160       +9     
============================================
  Files            32       34       +2     
  Lines           488      518      +30     
============================================
+ Hits            478      508      +30     
  Misses           10       10              

Files with missing lines	Coverage Δ
...Resolver/ConfigurationBasedAccessTokenResolver.php	100.00% <100.00%> (ø)
src/DependencyInjection/Configuration.php	98.80% <100.00%> (+0.05%)	⬆️
...EventSubscriber/DispatchOnCommandBusSubscriber.php	100.00% <100.00%> (ø)
src/Message/Command/SendEvent.php	100.00% <100.00%> (ø)
src/Message/Handler/SendEventHandler.php	100.00% <100.00%> (ø)
src/Message/PreparedEvent.php	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

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

[loevgaard]

The two latent PreparedEvent issues from the review — the phantom eventId/eventTime/actionSource, and getPayload() ignoring $context — are deliberately left as they are. PreparedEvent only exists because the SDK client has no way to accept a prepared payload; that is now Setono/meta-conversions-api-php-sdk#15. Once the SDK has Payload and Client::sendPayload(), this PR drops PreparedEvent and both issues disappear with it.