/v1/regard-device-attribute-value-changes has inconsistent error handling

The service returns inconsistent responses.

I noticed the following when calling the service. If I call the service with the responseBody containg

204: (A) a valid object path
- (B) this is also the case if the attribute-name points to a non existent attribute
500: an invalid object path -> returns a 500, internal server error
- (C) the object-path becomes invalid if the mountName and/or ltp is unknown
- (D) and/or if the path in general is not known

See examples below.

Having a 500 for unknown mountName/ltp combination but having no error for an unknown attribute is kinda incosistent.
Also the error messages are not meaningful

Initially I expected to always get a 204, as long as the requestBody follows the correct format (i.e. independent of the actual attribute values).
Having an error response if the object-path is unknown might be reasonable
- if we return an error response for that, the message should indicate why we got an error
- but we possibly might need to differentiate between a path that's wrong because (a) there is no related API path and (b) because the MWDI doesn't have the device/ltp combination in it's cache
- also we are currently aligning on error codes, so depending on the outcome we might need to change the error response code (this also may impact the error message; I could also image 400: Bad request could be a candidate).

Examples:

A: returns 204, all fine
{
  "notification-proxy-1-0:attribute-value-changed-notification":
  {
    "counter": 1,
    "timestamp": "2024-06-06T11:41:08.0+00:00",
    "object-path": "/core-model-1-4:network-control-domain=live/control-construct=513250006/logical-termination-point=LTP-MWPS-TTP-ODU-A/ltp-augment-1-0:ltp-augment-pac",
    "attribute-name": "external-label",
    "new-value": "513249876A"
  }
}
--------------------------------------------------------------
B: unknown attribute-name, still returns 204
{
  "notification-proxy-1-0:attribute-value-changed-notification":
  {
    "counter": 1,
    "timestamp": "2024-06-06T11:41:08.0+00:00",
    "object-path": "/core-model-1-4:network-control-domain=live/control-construct=513250006/logical-termination-point=LTP-MWPS-TTP-ODU-A/ltp-augment-1-0:ltp-augment-pac",
    "attribute-name": "some-unknown-attribute",
    "new-value": "513249876A"
  }
}
--------------------------------------------------------------
C: invalid object-path due to unknown mountName/ltp combination
{
  "notification-proxy-1-0:attribute-value-changed-notification":
  {
    "counter": 1,
    "timestamp": "2024-06-06T11:41:08.0+00:00",
    "object-path": "/core-model-1-4:network-control-domain=live/control-construct=513250006/logical-termination-point=someUnknownLtp/ltp-augment-1-0:ltp-augment-pac",
    "attribute-name": "external-label",
    "new-value": "513249876A"
  }
}
--------------------------------------------------------------
D: invalid object-path due to invalid path itself
{
  "notification-proxy-1-0:attribute-value-changed-notification":
  {
    "counter": 1,
    "timestamp": "2024-06-06T11:41:08.0+00:00",
    "object-path": "/core-model-1-4:network-control-domain=live/control-construct={a-valid-mountName}/logical-termination-point={a-valid-LTP}/some-unknown-class",
    "attribute-name": "external-label",
    "new-value": "513249876A"
  }
}

Screenshots:

openBackhaul / MicroWaveDeviceInventory

/v1/regard-device-attribute-value-changes has inconsistent error handling #983