EP for activity generating code refactor

[MikeJeffers]

Much like threat, these happen all over the place, and have a lot of duplicate logic, and arbitrary modifiers that would be nice to consolidate into one place for each bespoke activity. This will make balancing, debugging, and adding new EP activities easier!

Here are just some of the places you can find such code: https://github.com/OpenPerpetuum/PerpetuumServer/blob/Development/src/Perpetuum/Services/Relics/Relics/AbstractRelic.cs#L141-L150 (note the zone check for x0 or x2) https://github.com/OpenPerpetuum/PerpetuumServer/blob/Development/src/Perpetuum/Zones/Artifacts/Scanners/ArtifactScanner.cs#L59-L61 https://github.com/OpenPerpetuum/PerpetuumServer/blob/Development/src/Perpetuum/Modules/HarvesterModule.cs#L32-L39

and plenty more (find all references for EpForActivityType)

This one will not be as easy as there is a lot of logic based on some local state especially for missions etc. But there is likely an opportunity to create an abstraction, and maybe a delegate pattern to compute the bespoke EP value logic, and then handle the common manipulations.

2nd (optional) enhancement might be to do the insert in a separate task, but beware to pre-compute the values in the scope of the calling thread or transaction to avoid reading shared memory - where the main threat might (want to) be disposing, nulling, data you are reading(!). And make a separate transaction for the EP insert. Assess performance gains/losses for this and pursue accordingly - there may be occasions where many are getting EP activity rewards at once, and you might lose performance gain to the overhead of having them happen in separate transactions (where they were part of 1 big one of an NPC kill or mission completion).

[Ramit110]

Started work on this in https://github.com/Ramit110/PerpetuumServer/tree/issue-%23433