see SL-13565

This reverts commit d77b7bdc.

This reverts commit 6c1a15d9.

Convoluted due to multiple workarounds. Might be a good idea to spend some time refactoring this, but for now just trottled checks.

Depends onto SL-13979 for proper logging

LLSingleton depends onto logging system, having logging system be based on LLSingleton causes crashes and deadlocks

Remove the sleep throttle applied in 10625 to work around an Intel GPU driver
bug. It was erroneously being applied to all GPUs, and also as of Intel driver
26.20.100.7755 (1/9/2020) it appears that the driver bug no longer exists.

This fails at teamcity due to missing LLTrans, but builds locally without issues. Reverting to not hold D501

SL-12090 Initialize the joystick only when required

* SL-12090 Initialize the joystick only when required

Approved-by: Andrey Kleshchev

Changes were moved to DRTVWR-514

Reverted LLImage to singleton conversion

Superficially it looks like mac tried to resume ms_sleep after class got destroyed by regular cleanup.

The observed crash was due to sharing a stateful global resource (the global
LLMessageSystem instance) between different tasks. Specifically, a coroutine
sets its mMessageReader one way, expecting that value to persist until it's
done with message parsing, but another coroutine sneaks in at a suspension
point and sets it differently.

Introduce LockMessageReader and LockMessageChecker classes, which must be
instantiated by a consumer of the resource. The constructor of each locks a
coroutine-aware mutex, so that for the lifetime of the lock object no other
coroutine can instantiate another.

Refactor the code so that LLMessageSystem::mMessageReader can only be modified
by LockMessageReader, not by direct assignment. mMessageReader is now an
instance of LLMessageReaderPointer, which supports dereferencing and
comparison but not assignment. Only LockMessageReader can change its value.

LockMessageReader addresses the use case in which the specific mMessageReader
value need only persist for the duration of a single method call. Add an
instance in LLMessageHandlerBridge::post().

LockMessageChecker is a subclass of LockMessageReader: both lock the same
mutex. LockMessageChecker addresses the use case in which the specific
mMessageReader value must persist across multiple method calls. Modify the
methods in question to require a LockMessageChecker instance. Provide
LockMessageChecker forwarding methods to facilitate calling the underlying
LLMessageSystem methods via the LockMessageChecker instance.

Add LockMessageChecker instances to LLAppViewer::idleNetwork(), a couple cases
in idle_startup() and LLMessageSystem::establishBidirectionalTrust().

This reverts commit 4c006e76.
Since EEP there are no 'basic shaders' and doing this in llfloatersettingsdebug was wrong either way

SL-12090 Initialize the joystick only when required

* SL-12090 Initialize the joystick only when required

Approved-by: Andrey Kleshchev

Opaque water is not compatible with ALM

Pick up first version of new Dullahan build autobuild scripts that builds CEF wrapper first before building Dullahan. Change to version headers meant a change to appviewer.cpp too.

which performs "by hand" the same sequence of calls found in stepFrame().

Why not simply call stepFrame()? Hysterical reasons?

Longtime fans will remember that the "dcoroutine" library is a Google Summer
of Code project by Giovanni P. Deretta. He originally called it
"Boost.Coroutine," and we originally added it to our 3p-boost autobuild
package as such. But when the official Boost.Coroutine library came along
(with a very different API), and we still needed the API of the GSoC project,
we renamed the unofficial one "dcoroutine" to allow coexistence.

The "dcoroutine" library had an internal low-level API more or less analogous
to Boost.Context. We later introduced an implementation of that internal API
based on Boost.Context, a step towards eliminating the GSoC code in favor of
official, supported Boost code.

However, recent versions of Boost.Context no longer support the API on which
we built the shim for "dcoroutine." We started down the path of reimplementing
that shim using the current Boost.Context API -- then realized that it's time
to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
which we've been itching to do for literally years now.

Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
the differences between "dcoroutine" and Boost.Fiber.

The one feature Boost.Fiber does not provide is the ability to forcibly
terminate some other fiber. Accordingly, disable LLCoros::kill() and
LLCoprocedureManager::shutdown(). The only known shutdown() call was in
LLCoprocedurePool's destructor.

We also took the opportunity to remove postAndSuspend2() and its associated
machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
when the Responder pattern was king, and we assumed we'd want to listen on one
LLEventPump with the success handler and on another with the error handler. We
have never actually used that in practice. Remove associated tests, of course.

There is one other semantic difference that necessitates patching a number of
tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
ready to resume next time the scheduler gets around to it. To observe the test
side effects, we've inserted a number of llcoro::suspend() calls -- also in
the main loop.

For a long time we retained a single unit test exercising the raw "dcoroutine"
API. Remove that.

Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
that, remove the hack.

In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
tracking in place of llcoro::get_id().

In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
don't actually use the Boost.Coroutine for anything (though there exist
plausible use cases).

Make LLAppViewer retrieve release notes from LLVersionInfo, rather than
synthesizing the release-notes URL itself based on the viewer version string.

This changeset is meant to exemplify how to convert a "namespace" class whose
methods are static -- and whose data are module-static -- to an LLSingleton.
LLVersionInfo has no initClass() or cleanupClass() methods, but the general
idea is the same.

* Derive the class from LLSingleton<T>:
  class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... };
* Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This
  usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as
  described in indra/llcommon/llsingleton.h.
* Move module-scope data in the .cpp file to non-static class members. Change
  any sVariableName to mVariableName to avoid being outright misleading.
* Make static class methods non-static. Remove '//static' comments from method
  definitions as needed.
* For LLVersionInfo specifically, the 'const std::string&' return type was
  replaced with 'std::string'. Returning a reference to a static or a member,
  const or otherwise, is an anti-pattern: the interface constrains the
  implementation, prohibiting possibly later returning a temporary (an
  expression).
* For LLVersionInfo specifically, 'const S32' return type was replaced with
  simple 'S32'. 'const' is just noise in that usage.
* Simple member initialization (e.g. the original initializer expressions for
  static variables) can be done with member{ value } initializers (no examples
  here though).
* Delete initClass() method.
* LLSingleton's forté is of course lazy initialization. It might work to
  simply delete any calls to initClass(). But if there are side effects that
  must happen at that moment, replace LLSomeSingleton::initClass() with
  (void)LLSomeSingleton::instance();
* Most initClass() initialization can be done in the constructor, as would
  normally be the case.
* Initialization that might cause a circular LLSingleton reference should be
  moved to initSingleton(). Override 'void initSingleton();' should be private.
* For LLVersionInfo specifically, certain initialization that used to be
  lazily performed was made unconditional, due to its low cost.
* For LLVersionInfo specifically, certain initialization involved calling
  methods that have become non-static. This was moved to initSingleton()
  because, in a constructor body, 'this' does not yet point to the enclosing
  class.
* Delete cleanupClass() method.
* There is already a generic LLSingletonBase::deleteAll() call in
  LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned
  up with all the rest. But if there are side effects that must happen at that
  moment, replace LLSomeSingleton::cleanupClass() with
  LLSomeSingleton::deleteSingleton(). That said, much of the benefit of
  converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton
  dependencies will be properly honored: we're trying to migrate the code base
  away from the present fragile manual cleanup sequence.
* Most cleanupClass() cleanup can be done in the destructor, as would normally
  be the case.
* Cleanup that might throw an exception should be moved to cleanupSingleton().
  Override 'void cleanupSingleton();' should be private.
* Within LLSomeSingleton methods, remove any existing
  LLSomeSingleton::methodName() qualification: simple methodName() is better.
* In the rest of the code base, convert most LLSomeSingleton::methodName()
  references to LLSomeSingleton::instance().methodName(). (Prefer instance() to
  getInstance() because a reference does not admit the possibility of NULL.)
* Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged.

In general, for many successive references to an LLSingleton instance, it
can be useful to capture the instance() as in:

auto& versionInfo{LLVersionInfo::instance()};
// ... versionInfo.getVersion() ...

We did not do that here only to simplify the code review.

The STRINGIZE(expression) macro encapsulates:
std::ostringstream out;
out << expression;
return out.str();
We used that in a couple places.

For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a
couple specific static methods. It's harder to dummy out
LLSingleton::instance() references, so we add the real class to that test.