Adds support for Shopkeeper plugin

[Aquaxoc]

Adds support for Shopkeeper plugin (#145)

Checks if the entity is a shopkeeper with metadata and added an entry in the config.

[RoboMWM]

Like I do with PrettySimpleShop, the shop plugin should probably not ignore the event if it's canceled. This will also automatically make it compatible with other region plugins as well. There are no use cases that I know of where you'd want a plugin to blanket-deny access to shops.

Though - if you're trying to avoid the error message, then it should listen at a lower priority and cancel.

[ElementW]

@RoboMWM

the shop plugin should probably not ignore the event if it's canceled

This incites plugins to disregard the incremental checks & cancellation the API provides to have plugins like GP work in the first place. It is not the responsibility of higher priority plugins to accommodate, as part of their normal flow of operation, quirks of lower priority protection plugins because of their lack of ability to create check exclusion rules. GP has neither declarative (YAML) or API ways to request a specific type of entity and/or metadata to bypass checks, and that's a shame.

If this PR was made generic and allows for configurable Entity.hasMetadata()-based check bypasses, would you accept it?

if you're trying to avoid the error message, then it should listen at a lower priority and cancel.

https://github.com/TechFortress/GriefPrevention/blob/5a70d694e7accde180c7d805ec5d83f4a08551fb/src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java#L1166-L1167

https://github.com/TechFortress/GriefPrevention/blob/5a70d694e7accde180c7d805ec5d83f4a08551fb/src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java#L1315

There is no lower level than LOWEST, and you should know that the Bukkit/Spigot API & plugin system make no guarantee of run order on the same priority level, making your suggestion wonky at best since results will be unpredictable, which is exactly what @Aquaxoc and I observered between multiple server configurations as Shopkeepers already listens on LOWEST on the particular entity interact event that's causing trouble (LivingEntityShopListener.java:75-76).

[RoboMWM]

event priorities will be changed in v19 (or whenever the event funnel is implemented). This will also include a way to make GP ignore based on whatever you want as well. See dev/v20 branch for an example of such an implementation.

I'll take a PR to move it to LOW though. (That being said, there is a guarantee - if your plugin loads/registers before another, then your event handler will fire before another on the same priority; you can also loadbefore too.)

GP has neither declarative (YAML) or API ways to request a specific type of entity and/or metadata to bypass checks, and that's a shame.

That's coming with v18.

[RoboMWM]

I could also accept a PR like this in the meantime, probably without a config option I guess.

[blablubbabc]

I happen to come across this PR (I have several plugin users that run into the issue this PR intends to resolve from time to time) and wanted to note that I might have come up with another (and more generally applicable) solution.
The Shopkeepers plugin already has a 'loadbefore' entry to load before the GriefPrevention plugin (which already is not an ideal solution, because it requires being aware of conflicting plugins), so that Shopkeepers' event handlers execute first, cancel the event, and can thereby cause GriefPrevention to ignore the event. However, this broke whenever the Shopkeepers plugin has been dynamically reloaded (which re-registered its event handlers and thereby moved them to the end of the already registered event handlers of other plugins, such as GriefPrevention).
The next version of Shopkeepers will now forcefully re-register all other plugins' event handlers whenever it is reloaded, so that they get moved to the back of the registered listeners as well (this should be transparent to those other plugins, and also preserve their order among each other). This should ensure that Shopkeepers' event handler(s) always execute first, even after being dynamically reloaded, and thereby resolve this issue. A quick test on my side has confirmed that this seems to work as intended.
(If there are plugins that actually want to execute before Shopkeepers' event handlers or want to cancel its action, there are other means available for that)

Edit: However, regardless of this particular issue potentially being resolved then, this shouldn't hinder GriefPrevention to reconsider its used event priorities. For instance, if I remember correctly, WorldGuard uses normal event priorities for its checks, thereby allowing other plugins to pick if they want to execute before that (and thereby providing behavior that is more specific than the quite general land protection behavior) or after that (to take into account if the event has already been cancelled by another plugin).

[RoboMWM]

Yea, very likely will be moving checks to LOW priority.