Support for S3 daily buckets

[juhassi]

This is a works for me version of S3 daily bucket support for Filesender. I'll continue testing this a bit and if I don't find any real issues, we might be inviting some of our real users to test-drive this during next few months.

When storage_type is set to CloudS3, daily buckets can be enabled with $config['cloud_s3_use_daily_bucket'] = true;
Bucket naming prefix can be set with cloud_s3_bucket_prefix. Bucket name will be prefix + YYYY-MM-DD, for example:

$config['storage_type'] = 'CloudS3';
$config['cloud_s3_use_daily_bucket'] = true;
$config['cloud_s3_bucket_prefix'] = "Demo-";

Would today use bucket Demo-2023-04-27. Buckets are created (and removed when no longer needed) by cron.php, there is also scripts/task/S3bucketmaintenance.php that can be run to do only daily bucket maintenance when needed (mainly if you've just turned this on and need to have the daily buckets created asap).

Whenever maintenance script is run, list of existing buckets is fetched from S3. If they don't already exist, new daily buckets will be generated for today + 14 next days. Then all old buckets will be checked for contents and if they are empty, they'll be removed.

If today's bucket does not exist, all transfers will fail with a generic exception. For this reason, buckets are generated a bit in advance to allow administrators some breathing room in situations when new buckets can't be created (too many buckets already created error etc) -- I hope everybody is looking at their cron job's error emails :-)

Also, as a general note, performance with S3 backend can be greatly increased by bumping up upload_chunk_size and related values. My test system is performing adequately with:

$config['upload_chunk_size'] = 1024 * 1024 * 40;
$config['upload_crypted_chunk_size'] = $config['upload_chunk_size'] + 32;
$config['download_chunk_size'] = $config['upload_chunk_size'];

Increasing upload_chunk_size also requires you to verify PHP's memory limit is equal or bigger than about 5x upload_chunk_size.

[github-actions]

If there are selenium UI results for this code they will be at filesenderuici@791f15d

[github-actions]

If there are selenium UI results for this code they will be at filesenderuici@5a5898d

[github-actions]

If there are selenium UI results for this code they will be at filesenderuici@5e46900

[juhassi]

Also added some documentation updates to this PR.

[monkeyiq]

Looks good. Thanks!

I have a few little things which I might update next.

[monkeyiq]

I have put your performance information into #1459 and merged it to prevent it being lost / buried.

[juhassi]

Changing chunk_size invalidates all already uploaded files when using chunked storage methods (as then filesender doesn't know what used to be the chunk_size for that particular download -> it can't request proper objects from backend storage).

I'm thinking if it would be a good idea to include current chunk_size as option when creating a Transfer and use that instead of currently configured chunk_size when accessing files in that particular Transfer.

[monkeyiq]

I like this idea. I think the current chunk_size is referenced in crypto_app.js a bit and would need to be refactored to use either transfer->chunk_size or file->chunk_size. The classes/data/File class already stores the storage_class_name used when a file was created so it seems a logical place to put the chunk_size too.