SI-2471-burn-vehicle

[Allyson-English]

• add GET and POST endpoints to burn a minted vehicle
  • GET /v1/vehicle/:tokenID/commands/burn
  • POST /v1/vehicle/:tokenID/commands/burn
• handler for VehicleBurnedEvent in contract event consumer
• update udOwner.Delete("/", userDeviceController.DeleteUserDevice); check if device has been minted; if yes, return an error (StatusFailedDependency, 424) and instruct the user to burn the device
• tests

NOTES:

• do we want to keep /commands in the burn endpoint path? This is consistent with what we have elsewhere but it could also make sense to make the path /v1/vehicle/:tokenID/burn
• is StatusFailedDependency (424) the best error code to return from the DeleteUserDevice endpoint? I was aiming to make it distinct from other errors returned by that function to make it easier for the frontend to handle

[linear]

SI-2471 Vehicle burning

[elffjs]

Do we have a handler for VehicleNodeBurned (or Transfer to the zero address) already? Maybe that should be the first PR, now that I think about it.

[KevinJoiner]

I didn't finish looking at this, but I took a first glance. I think 424 makes sense as a return code.

[KevinJoiner]

The error handler will log on our behalf unless we explicitly call helpers.SkipErrorLog(c) which we do not.

A good general guideline for most Go functions is that you do not want to log and return an error. Since a function can never guarantee who will be calling it, that function does not know if the caller wants the errors logged or not, so it's best to just return the error and let the caller decide what to do with it.
A situation where you would log and return is if the error contains sensitive information you do not want to give to the calling function. In that situation it may be acceptable to log a detail error message and then return a general message to the user. An example of this is when APIs returning a general 500 Internal Error, but log more specific details.