WIP: Pickup slot fairness update (80% Fixed with !874?)

Intorduction

I'm kinda using this MR as a feature documentation. This idea started at hackweek with the simple plan to push the slot release time to something like 03:00 am. Followed by the idea of random slot generation leading to changing a whole lot more. My main motivation for this was to fight unfair behaviour of "midnight slot camping" and having settings for a more granular prefetchtime. It was very important for me to improve features to make life for users and store managers easier. I tried to improve the code as much as possible. It was a very big mess before and I hope it is a little bit less messy...

Improvement

• Manual pickup slots which used to disappear the minute after the pickup time ended are now displayed till 23:59
• Future MANUAL pickup slots are displayed and joinable no matter the automatic prefetchtime limit (only used to be displayed in prefetchtime range). Could be useful for festival organisation and longtime planning.
• It is finally possible to select more granular time ranges and even less than two weeks since it was buggy with the previous logic
• Slots are displayed at midnight but activated at a random time to prevent "midnight slot camping" ;-). This random time is different for each store and will be different on the next day but is the same value for 24 hours.
• Switching from e.g. 28 days to 7 days via store settings the whole slot range from now till the last actually occupied slot is visible - but it still is only possible to join by the (e.g. 7) day prefetchtime range of this example. This is great for transitioning/migrating between different timerange settings.

Has been like this before

• Changing the automatic time leaves foodsavers still signed in but not displayed #124 (closed). BIEBs are aware of it from past behaviour and act accordingly. I don't plan to touch this with this "release" since I have to dig even deeper and I want to put something out which already is helpful for the user. At the same time this is one of the biggest problems of the slot system. Hard to find a good solution notifying the user.
• You can't accept past pickups (if they aren't already confirmed e.g. by #406 auto-confirm ). Problems are described below.

Some thoughts and decisions

Informing users about different slot behaviour

• I want to add "(new)" to store settings (Betrieb bearbeiten (neu)) so store managers are aware of this change and can read the description of the pickup time section which is also labeled with "(new)".
• This makes even more sense if @k.miklobusec releases his #406 auto-confirm feature hand in hand with this one. I will talk about relating problems later.
• I will update the changelog with a detailed version if everything is set (todo)

Displaying disabled slots

This will be controversial and I'm willing to think about it again. These are my thoughts:

• Showing disabled slots is good against visual checking the site for new slots against both human and robots.
• I believe people should write a "slot reservation wish" on the pinboard and being nice to each other instead of hitting refresh all day long.
• Adding these two additional clicks for them will hopefully bore them. On the other hand we could limit the join requests in backend in the future.
• Only showing "possible slots" could lead to an empty slot list for up to 24 hours if prefetchtime is 7d and there is only one pickup day per week!

Granular day setting

Inbetween the usual weeks: time ranges like 10, 17 or 24: this imitates the previous behaviour of the slot system and gives the user more choice. To be honest I need some of these inbetween-times for my own stores ;-)
Since I'm a huge beleiver in short time planning (while looking back at the pickup history) I'd rather remove everything above two weeks. Maybe the "inbetweenies" help picking the "one setting below the one we used to aim for".

Red warning message

Well I put a reminder of acting fair and thoughtful in the red warning message. Everyone who's managing a store knows towards which people this text is directed at. Would like to keep this message in a less aggressive way for future slots. As I am thinking about creating two different warning message for past and future pickups..

Allow joining past pickups? (problematic)

• Currently it's disabled to join past pickups with beta. We can discuss it but it needs a lot of thoughts and can otherwise lead to problems. Allowing it without having Kristijans #406 auto-confirm !763 (closed) enabled (at least for already past pickups) would lead to unconfirmed pickups which will be deleted via an already in place "nightly run". Enabling (currently disabled) moderation of these slots for store managers allows them to "change the past" (at least in a limited range of time) while users can't change it. Killing this "nightly run" would help us keeping this info. Maybe even for pickup history.
• Current production version lets you join past pickups but you can't sign off from. A store manager can't confirm or delete you. This at least helps displaying a foodsaver who "jumped in" a pickup time with an unspecific actual pickup time sometime around a time range. Displayed at least if unconfirmed till 23:59...
• It could also lead to people joining 23:59 with #406 auto-confirm enabled just to bump thier pickup count / kgs...
• Issue #438 (closed) and some others are discussing this and I have a bad feeling to which discussions allowing it would lead.

Challenges / Painpoints

• There are a looot of different date strings, time strings and string formats
• Mixture of date objects and strings
• Different string formats of date + time combination wich often are used as the key/index of arrays (to match/merge manual and automatic pickups)
• Explode functions to get date or time with array positions
• I didn't convert anything UI related into twig or something. There is still a lot of php/css/js view code in classes... and a lot of potential for improvement... maybe with somebody in collaboration? ;-)

Current bug(s) / help?

• fixed

Final words

Please be aware of there is still some debug code in there. As mentioned in my previous MR text it will be gone as being closer to release to master. I'm happy about your input when it comes to improving things. I'm aiming for a "good enough" approach and will probably stick around improving/fixing thinks the slot topic even more. I already find #124 (closed) #535 (closed) #438 (closed) #232 (closed) quite interesting.