Metadata is stored for a new visitor whose cookie was vetoed #18

Summary

When a PreStoreCookieEvent listener vetoes the cookie ($event->store = false) for a visitor without a cookie, StoreMetadataSubscriber still persists that visitor's metadata. The row is stored under a client id the visitor never receives, so no later request can read it, and it stays in setono_client__metadata for good.

A typical reason to veto the cookie is a visitor who hasn't consented to cookies. An application that stores tracking parameters on landing pages then gets an unreachable row for every visit without consent. Storing data about such a visitor may also not be wanted at all.

Reproduction

In the test application from #13, SkipCookieSubscriber vetoes the cookie when the request has a skip_cookie parameter:

$this->browser->request('GET', '/metadata/set?key=foo&value=bar&skip_cookie=1');

self::assertResponseNotHasCookie('setono_client_id'); // passes
self::assertSame(0, self::countStoredMetadata());     // fails: 1 row is stored

Cause

StoreCookieSubscriber (kernel.response) and StoreMetadataSubscriber (kernel.finish_request) decide independently. The veto only stops the cookie.

Possible fix

Don't persist the metadata of a new client whose cookie wasn't stored. For example, StoreCookieSubscriber could mark the request when the cookie is vetoed, and StoreMetadataSubscriber could skip persisting for a client that came without a cookie.

PR #11 also changes this, as part of deferring the metadata of new clients (#8).