Inconsistency in current Location of a Thing when Historical Locations are deleted or updated

[basvandenbrink-infosupport]

Description of the Issue: While the API successfully updates the current Location of a Thing when a new HistoricalLocation is added, it does not reflect the deletion or update of a HistoricalLocation in the current Location of a Thing. This inconsistency could lead to incorrect data being presented to the API consumers, especially when Locations are actively managed and updated.

Steps to Reproduce:

1. Create a Thing
2. Assign a Historical Location: Send a POST request to /Things('SOME ID')/HistoricalLocations with a payload that assigns a Location. The Thing has automatically been assigned a Location.
3. Assign a Second HistoricalLocation: Repeat the previous step and create a new Location and HistoricalLocation with a newer time than the previous entry. The Thing has automatically been assigned this new Location.
4. Delete the second HistoricalLocation: Send a DELETE request to remove the second (newest) HistoricalLocation.
5. Verify Inconsistency: Fetch the Thing details, expanding the Locations and HistoricalLocations. Observe that the current Location remains unchanged despite the deletion of its corresponding HistoricalLocation.
   Expected Behavior: Upon the deletion or update of a HistoricalLocation, the current Location of the Thing should be updated to reflect the most recent remaining HistoricalLocation, if available, or show no current Location if none remain.

Actual Behavior: The current Location of the Thing remains unchanged, showing the Location of the HistoricalLocation that was previously deleted.

[hylkevds]

Yes, the spec only specifies what should happen when a user adds a HistoricalLocation. So far we've not had use cases where the last HL is removed, so that logic is currently not implemented.