Allow mounting /tmp as tempfs in service containers

[kam193]

Is your feature request related to a problem? Please describe.
When investigating some performance issues, I've noticed that some tools (aka semgrep) love to write a lot of temporary information. In addition, every service always needs to store some temporary files and eventually, the submitted file itself.

I think it may be useful to allow optional mounting /tmp as tempfs to leverage the RAM speed.

Describe the solution you'd like
An option to enable the tempfs and configure its size in the settings of the service container, in the simplest form just the hardcoded for /tmp path.

Describe alternatives you've considered
A more advanced configuration that allows setting specific paths, so e.g. update's path outside /tmp could be set to be tempfs - but I don't think it's worth it, only /tmp should be temporary, and the update's path could be set to be there.

Additional context
I don't think tempfs is generally the best, but it could be useful in some specific scenarios - so I'd like to give administrators an option to allow it. I'm currently testing it with a modified scaler with a hardcoded mount for a one volume, and the first impression is that it works great. But I have to wait a little more to be sure that this what made the change.

[kam193]

BTW, for services that don't need the file at all (aka badlist etc.), it could be interesting how e.g. 10 MB tempfs would influence the performance 🤔 I'm not sure if it would be visible, but on the other hand RAM is still much quicker than any disk. I can imagine that if the service itself is very quick and workload high, the time of temporary saving tasks and results may play a role. But maybe it's just an imagination 😄