build: Remove remaining circular link dependencies

[rrsettgast]

This PR seeks to remove remaining circular link dependencies.

• Move OutputBase::getOutputDirectory() to a lower level component to avoid dependencies on fileIO
• Move constitutive drivers to their own component (constitutiveDrivers).
• remove reliance on ProblemManager::getPhysicsSolverManager() functions and insert hard coded getGroup( "Solvers" ) function. Not optimal, but gets rid of the circular dependency.
• reintruduce shared library option
• remove shared geosx_core created using blt_combine_static_libraries
• remove GEOS_LINK_PREPEND_FLAG and GEOS_LINK_POSTPEND_FLAG in favor of cmake $<LINK_LIBRARY:WHOLE_ARCHIVE,${lib}> option.
• update all paths in documentation as a result of creation of constitutiveDrivers module.
• cleanup unit test dependencies

Here is the dependency tree. Note that this doesn't resolve circular header dependencies.

[codecov]

Codecov Report

Attention: Patch coverage is 82.75862% with 5 lines in your changes missing coverage. Please review.

Project coverage is 56.00%. Comparing base (4d4eb35) to head (0cedfed).
Report is 89 commits behind head on develop.

Files with missing lines	Patch %	Lines
...lvers/multiphysics/PoromechanicsInitialization.cpp	0.00%	3 Missing ⚠️
...olvers/solidMechanics/SolidMechanicsStateReset.cpp	0.00%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #3282   +/-   ##
========================================
  Coverage    55.99%   56.00%           
========================================
  Files         1053     1053           
  Lines        89157    89168   +11     
========================================
+ Hits         49921    49935   +14     
+ Misses       39236    39233    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[MelReyCG]

@rrsettgast About OutputBase::getOutputDirectory():
What do you think of a static string Path::getOutputDirectory() (along with the setter too)? Or, at least, to relocate it in src/common/*?

[rrsettgast]

@rrsettgast About OutputBase::getOutputDirectory(): What do you think of a static string Path::getOutputDirectory() (along with the setter too)? Or, at least, to relocate it in src/common/*?

I think this is the only solution. I just hadn't done it yet.

[MelReyCG]

@rrsettgast

To avoid to rely on Group tree assomptions like...

  Group & problemManager = this->getGroupByPath( "/Problem" );
  Group & physicsSolverManager = problemManager.getGroup( "Solvers" );

... I would like to suggest two options:

---

Option 1. Split ProblemManager in two classes to invert the dependency:

1. ProblemManagerABC or ProblemManagerBase: located in dataRepository, it would be a shallow class which would mainly expose mainly the different assessors for the sub-managers, along with the view-keys (we can also imagine a static method to get it getRoot( Group const & anyGroup ) or with a singleton getInstance()),
2. ProblemManager or ProblemManagerImpl: located in mainInterface, it would contain the concrete behaviour / management methods (problemSetup(), runSimulation().

---

Option 2. Expose the ProblemManager::groupKeysStruct view-keys in a dedicated file in dataRepository, maybe with methods for accessing them:

• T & getManager<T>( Group const & anyGroup, string_view managerViewKey )
• T const & getConstManager<T>( Group const & anyGroup, string_view managerViewKey )

[rrsettgast]

@rrsettgast

To avoid to rely on Group tree assomptions like...

  Group & problemManager = this->getGroupByPath( "/Problem" );
  Group & physicsSolverManager = problemManager.getGroup( "Solvers" );

... I would like to suggest two options:

Option 1. Split ProblemManager in two classes to invert the dependency:

1. ProblemManagerABC or ProblemManagerBase: located in dataRepository, it would be a shallow class which would mainly expose mainly the different assessors for the sub-managers, along with the view-keys (we can also imagine a static method to get it getRoot( Group const & anyGroup ) or with a singleton getInstance()),
2. ProblemManager or ProblemManagerImpl: located in mainInterface, it would contain the concrete behaviour / management methods (problemSetup(), runSimulation().

Option 2. Expose the ProblemManager::groupKeysStruct view-keys in a dedicated file in dataRepository, maybe with methods for accessing them:

• T & getManager<T>( Group const & anyGroup, string_view managerViewKey )
• T const & getConstManager<T>( Group const & anyGroup, string_view managerViewKey )

I think I would prefer to tackle this in a follow up PR. This one is kind of heavy already.

[rrsettgast]

@MelReyCG I did this instead of moving the outputDirectory up to common. We will have to come back and do something better later, but I didn't like the move option either....maybe we can discuss at the next meeting.

[MelReyCG]

I think I would prefer to tackle this in a follow up PR. This one is kind of heavy already.

@rrsettgast @wrtobin
No problem, what do you guys think of the suggestions? I can make a PR for the one you prefer.

[Algiane]

It is not possible to build Geos as a shared library on powerpc architecture (error at link edition).

As by default the GEOS_BUILD_SHARED_LIBS variable is enabled, we have to keep this line for the P3 host-config (at least until we fix the linke error, which is not a priority for us for now).

[paveltomin]

CC @drmichaeltcvx