Sync with changes in the private SLB repository

Sync with changes in the private SLB repository

• Consume a newer SDAPI in internal SLB builds.
• Add more telemetry and other debug code.
• Forgotten return statements are fatal in gcc.
• Make IOContext changes less likely to break the ABI.
• Add httpHeaders() to the IOContext.

IOContext details:

The existing class IOContext and derived implements the named parameter idiom for configuring I/O. Make IOContext changes less likely to break the ABI. Introduce a new SeismicStoreIOContextV2 that uses the pimpl pattern and that has no inlined functions. The main drawback is that a significant code bloat, and somewhat higher maintenance cost.

To avoid breaking the ABI right now, SeismicStoreIOContextV2 inherits from the unchanged SeismicStoreIOContext. So the pimpl pattern only applies to new members. On the next major release, consider moving everything into the pimpl.

Note the following minor inconvenience: Parameters in the new V2 class needs to be set before those in the old class. I could fix this, but that would lead to even more bloat.

This works:

  auto args = SeismicStoreIOContextV2().newparam(x).oldparam(y);

Also the longer version:

  SeismicStoreIOContextV2 args;
  args.oldparam(x);
  args.newparam(x); // either order.

This will not compile:

  auto args = SeismicStoreIOContextV2().oldparam(x).newparam(y);

The pull request adds a single new paramater using the new class. httpHeaders() will be passed on to SDAPI when creating an SDManager(). There is also a fallback environment variable OPENZGY_HTTP_HEADERS.

Applications that needs to use the new parameter can switch to use the new class exclusively.

Telemetry details:

Optionally record all read() and write() calls at the OpenZGY public API level.

The result is output in CSV format to the file specified in $OPENZGY_RECORD_LOGFILE. The idea is that a log file from Petrel could be used to replay the same access pattern using a stand alone tool. This could make it much easier to debug actual performance issues that Petrel is seeing. Note that I have not written the replay tool, only he logger.

Caveat: For multi-threaded access, even if the replay tool is multi-threaded, the replay might not be sufficiently similar to the original. It depends on how much effort we put into that new tool. And the problem being analyzed.