Application update events trigger zync when first*traffic_at fields are updated

We are having a daily HTTPClient::ReceiveTimeoutError error from Zync.

The reason is a customer cancelled the access permission to Keycloak, and as Zync can not access it, it keeps retrying.
But what we are doing wrong here is that we are notifying daily when we update first_traffic_at or first_daily_traffic_at, when, in fact, we shouldn't notify Zync only for this change as it is not updating any data in the client stored in RH SSO anyway.

Proposed solution

1) Change this line.
From cinstance.update_attribute(:first_traffic_at, object.timestamp)
to cinstance.update_column(:first_traffic_at, object.timestamp).
This way the updated_at of the record won't be touched and Zync won't be notified. This also implies muting rubocop for this with # rubocop:disable Rails/SkipsModelValidations and adding a test in Events::Importers::FirstTrafficImporterTest title because all this is not obvious.

2) Do exactly the same with this line and this test.

Note

Probably the proposed solution would work but we need to verify the impact on notifications, mails.

This was caused by an update to an existing feature (THREESCALE-1947) where we broke the workflow of a customer using a workaround: setting manually in the OIDC the OAuth flow to implicit.

The feature above, automatically synced through zync the OAuth flow. By default, we considered every customer is using the standard flow. But some of them were setting implicit flow manually as workaround.
Problem arise when when the first_traffic* fields (or any of service fields) are updated, an event is propagated to zync, overriding the OAuth flow in the customer OIDC, setting it to the default standard flow.