fix: revert differences in ModuleEnvironment from v5

[keturn]

There were a few changes in how ModuleEnvironment builds reflections and permissions between v5 and v7.

They are the sort of thing that look like they probably do make sense in many situations, but I think Terasology has things that depend on the old behavior.

I doubt we should really revert these entirely, but what should we do?

[keturn]

[GESTALTv7] migrate module & asset

[keturn]

Notes from today's meeting:

• The only stakeholder in gestalt-module other than Terasology is Destination Sol.
  • there aren't really other people we can talk to about what the impact of a change like this would be
  • but that also means there aren't other things to worry about breaking
• confusion about what exactly this change broke / what would be fixed if we revert it
  • @keturn is working on some integration test cases in Terasology to pinpoint that: do not allow modules to import unsafe engine classes Terasology#4639
    • then maybe we can figure out how to narrow those tests to gestalt-module's own test suite?
• keturn thinks we can work around the change to createPermissionProviderFor at the application level, but
• the change within buildFullReflections can't be overridden at another level
  • if necessary, we'll revert it, and put a note in some Architecture Decisions Log (which lives where?)

[keturn]

I guess the other option besides reverting it would be to twiddle some things around so the application can customize that behavior in a ModuleEnvironment subclass. But there's not much sense in doing that if we can't articulate why an application would choose one way over the other.

[jdrueckert]

Tested the following things before (release/v7.x) and after (v7/spike/modenv-vs-v5) this change:

• CoreGameplay -> looks the same both before and after
• Malicious tests -> before 1/2, after 2/2
• integration tests -> Health fails both before and after, new failure after in ModuleTestingEnvironment ModuleTestingEnvironment also fails before and after

I'm not really sure how to test a dist zip of iota. I tried with ./gradlew distZip but that gives me a .zip with the engine only.
Also I don't know whether there's further things we should test for this...?

FYI @skaldarnar @keturn

[jdrueckert]

Pre-GSoC Release

[jdrueckert]

To test a dist zip of iota I ended up doing the following:

1. ./gradlew distZip
2. copy facades/PC/build/distributions/Terasology-5.0.0-SNAPSHOT.zip some place else and unzip
3. copy module jars (from <module>/build/libs/) into <unzip dir>/modules/
4. start Terasology and start CoreGameplay

I observed that the game starts fine and looks as expected