Fix construction order of ServiceImpl and RequestSourceServiceImpl.

[mum4k]

Also re-enable test_gcc.

Fixes #872.

Details:

• ServiceImpl creates Envoy::Logger::Context which requires Envoy::Thread::MutexBasicLockable.
• The Envoy::Thread::MutexBasicLockable was constructed after the Envoy::Logger::Context, so Envoy::Logger::Context became invalid during destruction of ServiceImpl.
• this PR ensures that Envoy::Thread::MutexBasicLockable lives longer than Envoy::Logger::Context.
• Fixing the same problem in the construction of RequestSourceServiceImpl.

Reason for test_gcc failure:

• Only call ares_library_init()/cleanup() routines in process_wide() if ares extension used in DNS resolving. envoy#21884 triggered this bug, because it added a logging call initiated indirectly from the destructor of Envoy::ProcessWide.
• This logging call happened during the destruction of ServiceImpl when the Envoy::Thread::MutexBasicLockable instance was already destroyed.
• As a result the PURE virtual methods on its parent object Envoy::Thread::BasicLockable were called.
• test_gcc reported it because it places a special function meant to detect this behavior in the vtbl of unimplemented pure virtual methods.

Signed-off-by: Jakub Sobon mumak@google.com

[mum4k]

@eric846 please review and assign back to me once done.

[eric846]

LGTM