* Fix bulk importer parameter and remove unused method
-Fixes AddSwitchesBulk post-refactor by passing in the switch timestamp instead of a set of PKMembers
-Removes unused RegisterSwitches method which was replaced by AddSwitchesBulk
* Fix import from Tupperbox regression defect
When converting a Tupperbox import file to the PluralKit format on import, this sets the Tupper's name as the member ID which seems like a reasonable default. I'm also initializing the switches collection (even though it's going to be empty in this case).
This fixes a regression defect introduced when switch import was implemented.
* Making converted Tupper DataFileMember Id a GUID instead
Member names aren't necessarily unique (even if they should be), and no reason not to use something we know will be unique...
The frontpercent command already accepted time patterns (e.g. 9pm), but these were always being interpreted as UTC regardless of the system's configured zone. Furthermore, the time wasn't being nudged to the previous day, so if you tried to do pk;s fp 6pm at 5pm UTC, it would complain about the date being in the future instead of just showing you since 6pm yesterday.
The system zone is now respected and nudging enabled in the same manner as pk;sw move.
The member length limit is now long enough that it's unlikely to
hit the cap by accident. An error will still be displayed if you
attempt to perform a message proxy.
-Fixes AddSwitchesBulk post-refactor by passing in the switch timestamp instead of a set of PKMembers
-Removes unused RegisterSwitches method which was replaced by AddSwitchesBulk
We're now using binary import for switches and switch_members when importing a system profile, rather than importing them one switch at a time.
This adds a pass-through method to the PerformanceTrackingConnection that can be used for other bulk import applications.
Some of the command rewrite changes resulted in the response messages for importing a system being swapped. When importing without an existing system (ctx.System == null), we want to display the "new system" message. Otherwise, show the count added/modified.
A given system can now have up to 1000 members. Within 50 members of that limit, a warning will display whenever a new member is created via the bot. Once the limit is reached, a final warning will appear indicating that no additional members can be created unless members are first deleted. Attempting to create a new member at that point by any method will result in an error message indicating that the limit has been reached.
Respecting this in pk;import required some restructuring to tease apart which members already exist and which ones need to be created prior to creating any members as it seems preferable to fail early and give the user the ability to intervene rather than pushing the system to the member cap and requiring manual deletion of "lower priority" members before others can be created. One consequence of the restructure is that existing members are being read in bulk which is a performance improvement of 25-70% depending on how many switches need to be imported (the more members you have, the more noticeable this is).
