First implementation of recording data message being saved to filename + lots of dependency updates

[olokos]

This is the first implementation of the recording data being sent as a metadata struct, so it could be applied to the output filename of the recording.

I have also updated a lot of go and javascript (yarn/npm) dependencies.

I made Dockerfile to use node16 - since it's the latest LTS supported version aswell as some other improvements.

Each commits has quite well described commit message

With this commit I'm also updating develop branch to the current code state in master, so there will be no issues later on when merging this.

[olokos]

There are 2 bugs with this PR at the moment, that needs fixing before or after merging.

1. Sometimes saving # of changes to filename breaks saving the actual file, resulting in 1kb output file
2. Sometimes despite the pixel threshold is reached, it won't trigger saving of the recording, usually in a situation where there are 0 changes for a long time, then there's like 3 frames over threshold and the back to 0 frames, in that scenario the Agent will sometimes not record.
3. Once threshold is reached, the filename will save only the first # of changes that went over threshold, even if there were more changes in any of the following frames, the # of changes that first triggered saving will be kept in recording filename. - But that might be actually a desired feature, that would allow the user to tweak the pixelChangedThreshold better.

[olokos]

As for the bug 1 with 1kb recordings being saved, I suspect I might have introduced an infinite loop here:

Bug 2 might be related to the above screenshot

While with Bug 3 - I'm not sure how it was initially planned, but IMO it's quite good that it saves to filename the amount of changes that triggered saving, instead of the final/avg amount of changes saved into the filename, as it allows for better tweaking of that configuration file.

It's my first time working with golang, so bear with me :)

[olokos]

For reference, I've set the pixelChangeThreshold to 8000 here, so anything above 8000 pixels should already trigger the log with "Attempted to save changes"

More details about bug 2:

There's no "Attempted to save changes" log, as if it wouldn't save count to filename, right? Well, wrong, it did!

1660645374_6-967003_NaUliceKamera_200-200-400-400_8399_769.mp4

But as for the second time the threshold was reached, there was a log about saving changes to the filename: and the resulting filename is:

1660645408_6-967003_NaUliceKamera_200-200-400-400_8277_769.mp4

So technically it works great, but log print is delayed?

I think the approach is great to save the first frame changes that triggered the recording to filename, without playing around with averaging or taking the highest value, as it tells the user clearly how many pixels changed here that were enough for triggering saving the recording. But as can be seen on screenshots above, the message with changes is a bit buggy right now.