file_manager: Added event for metadata update

[kieraneglin]

I'm working on a component that should do some work after a file's metadata has been updated. This PR adds an event that fires when a file's metadata has been successfully parsed and updated.

Signed-off-by: Kieran Eglin kieran.eglin@gmail.com

[moggieuk]

Great idea. Lots of uses

[kieraneglin]

@Arksine is it possible to request a review here? I would also like to confirm whether the fname variable I'm passing would contain the full file path or just the file name without any directory information. If it's the latter, I'll need to update this to include that information

[Arksine]

Thanks, sorry for the delay. I do have a few observations:

• Previously Moonraker did emit a metadata update event, however it was removed after inotify support was added as it was not longer required. The file_manager:filelist_changed event triggers after metadata processing is complete, so remote clients may use that to perform operations that require metadata to be present. It is possible to filter using the create_file and create_dir actions on items within the gcodes root. The create_dir action indicates that a new folder has been created OR a folder has been copied. In the case of the latter metadata for all items within the folder has been processed.

• The filename is relative to the gcodes root. So for example if the file's full path is /home/pi/printer_data/gcodes/test_prints/cube.gcode then the fname will be test_prints/cube.gcode.

• Since this event isn't being emitted as a notification we dont need to wrap it within a dict object. It might be better to pass two arguments, the first being the filename, the second being the metadata itself.

• I'm not opposed to reintroducing a metadata event, however before merging there needs to be code within Moonraker to provide a rational basis for merging it. Additionally I'm currently reworking parts of how Moonraker handles metadata internally, so there is a possibility that this event could be refactored.