Add GET /keyframe/{uuid} endpoint for retrieving keyframes by UUID

[aeroith]

Implements a new API endpoint that retrieves a specific keyframe by its UUID and returns the raw frame bytes with metadata in response headers:

• Content-Type based on codec (video/h264, video/hevc, image/jpeg, etc.)
• X-Frame-UUID, X-Frame-Timestamp-NS, X-Frame-Codec
• X-Frame-Width, X-Frame-Height, X-Frame-Keyframe

[bwsw]

@aeroith thank you for the PR. I would like to comment on specific points that concern me:

Data return and structure. You expect that the first element contains frame content, which is not true. The content can be embedded in the frame itself, kept in the first data item, or stored in a 3rd-party system like KeyDb, where only a reference is stored in the frame or data. The implementation depends on adapters and their negotiation.

Thus, in general, you cannot determine where the data is without frame metadata. Therefore, you need to return [frame_metadata, all, data, items]. Probably, the best way to do that is to use multipart/mixed and return everything. For the metadata, you can implement an API to request either json (videoframe.json()) or native format, which means a protobuf-serialized Message.

The current implementation with headers and the first data item is not universally applicable and cannot be reliably used in systems that use other encoding schemes. Please take a look at our Kafka/Redis adapter for an example: frame contents are kept in Redis/KeyDB, while metadata travels over Kafka, containing only a reference to the storage. This is beneficial for systems that rely on data deduplication.

Keyframe limitation. You implemented it to request only keyframes; however, it would be better to support any frame. Keyframes are a logical concept, containing just a starting moment when you can decode a frame sequence. E.g., for JPEGs, you do not need to set KF on every JPEG, but also on some of them, like 1 per second or dynamically based on particular conditions (e.g., the scene started to contain something useful). Thus, KF (in the context of Replay) only defines the size of the seek index and may not reflect the 'autonomous decoding' property of a particular element.

[aeroith]

@bwsw Thank you so much. It makes much more sense now to me. I'll implement these changes later today, and let you know if I need more input.