Interserver Refactor

[Pheotis]

Currently, it is possible to make interserver networks that either do not integrate with, or outright conflict with, matching local networks. See issue #255.

The long-term solution to this should probably be to just extend local networks into interserver networks:

Take local custom network (foo). Also take interserver network ❪foo❫.

Given:

• Portal Test1 on ❪foo❫ on Server1

  
  Test1

foo I

- Portal `Test2` on ❪foo❫ on Server2

Test2

foo I

- Portal `Test3` on (foo) on Server1

Test3

foo

- Portal `Test4` on (foo) on Server1

Test4

foo

The listed portals shown from interserver portal Test1 should look like this:

• Test1 -

  Test2 < Test3 Test4

  The listed portals shown from local portal test3 should look like this:

• Test3 -

  Test1 < Test4

For the example test3, note that the interserver portal test1 would clearly be indicated as such by its colour.

As an exception to this rule, default networks should handled similar to how they already are.

Take local default network `<@@ DEFAULT @@>`.
For its interserver equivalent `❮ @@ DEFAULT @@❯`, the handling should work as follows.

Given:
- Portal `TestA` on local `[central]` on Server1

TestA

central

- Portal `TestB` on local `[central]` on Server1

TestB

central

- Portal `TestC` on interserver `【central】` on Server1

TestC

central I

- Portal `TestD` on interserver `【default】` on Server2

TestD

default I

The listed portals shown from interserver portal TestA should look like this:

• TestA -

  TestB < TestC

  The listed portals shown from local portal testC should look like this:

• TestC -

  TestA < TestB TestC

For personal portals, the functionality should be identical to that described above for local custom networks. For terminal portals, the functionality is not yet defined, but should likely be identical to that described above for default networks.

The general conflict handling for duplicate network names (as identified by our conflict management diagram in #237) should be extended for all interserver network gates.

This likely reflects a sweeping change in how interserver networks are implemented. If this change is too extensive given the upcoming beta push, we can probably expand conflict management to treat the interserver scope as functionally independent for the interim.

Also, this change is probably expansive enough to require its own branch.

[Thorinwasher]

This is a great idea, here's some issues we would need to face for even trying to deal with interserver conflict management:

• We would need to store the names of all local networks with their name and related server in the database. This is so that, when a server instance starts up, it will know all the local networks that already exist
• Any creation of a local network would require to send a bungeecoord pluginmessage, saying a local network has been created. Otherwise when a local network has been created, it will not register for the other server instances

[Thorinwasher]

And, yes. This would require quite a refactor to work, including loads of testing. This should really not be in the parity update, but later on, so that we can release some kind of beta version

Also, when I think about it, conflict management could be exactly the same as for interserver portals, that is if we implement the same functionalities as I mentioned above.

The main logic behind this post is (when I think about it) whether to have network centered behavior, or portal centered behavior, generally portal centered behavior might make more sense, as it's easier to see the status of a portal, rather than that for a network.