Locks do not send `locks.locked` when an automatic relock occurs

[seveibar]

Prerequisites

• Can this issue be reproduced in a sandbox workspace? Yes
• Does this issue represent a regression? Did it previously work? No

Description

Locks do not send locks.locked when an automatic relock occurs

Steps to Reproduce

1. Unlock is requested
2. Seam sends unlock request to device provider
3. Device provider acknowledges request
4. Seam emits lock.unlocked, but locked=true because the device provider hasnt changed state
5. Polling results in locked=true, implying a relock, but really we never changed it

Expected behavior: Expect to receive locks.locked when a relock occurs

Actual behavior: locks.locked is never emitted

Relevant Conversations

• https://hello-seam.slack.com/archives/C056LN2GAF8/p1688175053289789

[dawnho]

If it’s an electric strike, or door that defaults to being a locked door, we will only want to report "unlocked" events. Larger building access systems generally do not report locked events, as it will clutter up their event feed.

However, if the door is placed in an extended unlocked state (aka office mode), then the event tracker will log that, (see "Unlocked via schedule", "Locked via schedule", and the "Office Mode" events).

An example from Brivo:

An example from Salto: