www/squid: change cache_dir from ufs to rock

[AndyX90]

This pull-request changes the type of the squid cache_dir from ufs to rock.
We already included the workers in #4393 for smp-mode and should also move to rock as the cach_dir type, as rock is currently the only SMP-aware cache_dir type.

Testing happened on OPNSense 24.7.12 with enabled local ufs cache.
Switched to rock and it initialises the rock db in /var/squid/cache.
The pre-rock ufs data stays there until a reset via Squid Web Proxy --> Administration --> Support --> Reset is done.

More information: http://www.squid-cache.org/Doc/config/cache_dir/

[AdSchellevis]

The question is if we shouldn't offer a choice here, when switching from one storage type to another, quite some side-affects might happen (such as excessive disk usage due to duplicate caches). The diskd type might be less destructive by the way, but I haven't looked at the performance differences.

[AndyX90]

@AdSchellevis Thats a good question. My intention was to keep it simple and only support a cache_dir that is valid for all scenarios. Performance wise i read about the longer initialisation of the cache dir, but that doesn't affect squids startup. I also was not able to see any performance-regression in comparison to ufs(but my testing-cache was rather small). Related to the point of duplicate caches, i think it would be enough to make a note in the changelog, that squid content should be resettet via the ui once after the update to remove the old cache data.

[AndyX90]

Hi @AdSchellevis,
did you already have time to think about this?
I understand your concern about potential side effects when switching cache directory types.
However, after careful consideration, I believe that rock is the most suitable choice for several reasons:

• Rock is the only cache_dir type that supports SMP-mode, which is crucial for performance in multi-core environments. This makes it more efficient and scalable compared to ufs.
• By standardizing on rock, we maintain simplicity and reliability. Offering multiple choices could complicate the user experience and maintenance, especially considering the potential for misconfiguration and potential service-startup problems in non-supported combinations.
• While rock has a little longer initialization time, this should not hinder Squid's startup. In my testing, with a small cache, performance remained stable, and I didn't notice any regression.
• The transition from ufs to rock doesn't have to result in cache-data duplication. The user can reset cache dirs via the Squid Web Proxy UI. But on the other hand, I don't know if that many people actually use the cache and would be affected by a possible cache-dir migration.

I hope this is the right way to make Squid integration better. Let me know if you have any additional concerns or suggestions.

[AdSchellevis]

@AndyX90 I don't have a lot of time and squid isn't really a priority for us at the moment. I'll merge your PR as I don't have other concerns