WSTEAMA-1572: Remove "hashedId" to match sign-in status

[alex-magana]

Resolves JIRA [WSTEAMA-1572]

Overall changes

Removes the value, hashedId, from Reverb config since it sets the user ID instead of the visitor ID.

Background Context

Following this conversation, we investigated the usage of values set in the user object of the
Reverb configuration. The investigation revealed that the hashedId we've been passing in the Reverb
configuration for the purpose of setting the visitor ID was incorrect. This is because the hashedId which
we pass to Reverb via the function, getHashedId, is meant to track users instead of visitors.

Through conversations with the Reverb, we've established that Reverb manages the generation and
persistence of the visitor ID via the atuserid cookie. The values stored in atuserid is then reported
to Piano via the query parameter, idclient. We therefore don't need to manage the atuserid
cookie in Simorgh once we transition to Reverb.

The Reverb team recommended that we should retain the user object even though our audience
is not signed in and set the function, getHashedId to return null.

See WSTEAMA-1572 for link to Slack thread

Code changes

• Remove hashedId from the Reverb page view beacon configuration.
• Remove hashedId from the Reverb component tracking beacon configuration.

Testing

1. Visit http://localhost.bbc.com:7080/pidgin/articles/cevee1j7ymyo?renderer_env=live
2. Verify that page view and component event tracking beacons include the idclient query parameter.

Helpful Links

Add Links to useful resources related to this PR if applicable.

Coding Standards

Repository use guidelines