Rename library to datadog

[delner]

Rename the library from ddtrace to datadog to reflect the inclusive nature of many Datadog tools (tracing, profiling, ASM, etc).

2.0 Upgrade Guide notes

Users should use datadog instead of ddtrace in their requires, where applicable e.g.:

• gem 'ddtrace' --> gem 'datadog'
• require 'ddtrace' --> require 'datadog'
• DDTrace::VERSION --> Datadog::VERSION

It otherwise preserves all the same functionality & default behavior present in ddtrace.

What does this PR do?

A 1-1 name change of the ddtrace gem to datadog, updating relevant file names, constants, comments, and other references to the Ruby gem.

Motivation:

ddtrace as a name has not been reflective of the many products we include within the package, and the name was in conflict with the semantic conventions of Ruby (where gem name & file paths should mirror constants.)

Additional Notes:

TBD

How to test the change?

TBD

[delner]

Notes about development

There are quite a few changes here, and I think its worth segmenting them into what's a minimum, and what's additional.

Changes

• Change gem from ddtrace to datadog
• Migrate remaining ddtrace.rbandddtrace/files todatadogfiles, updaterequire`s.
• Update references to DDTrace to Datadog
• Update documentation to reflect new behavior.
• Update builds, tools, tests, and other automated processes.
• Update code comments (for less confusion)
• Update Faraday instrumentation to use datadog_tracing instead of ddtrace
• Update TRACER_VERSION to DATADOG_GEM_VERSION

Open questions

• Should we rename Datadog::Core::Environment::Ext::TRACER_VERSION (which was an alias to DDTrace::VERSION::STRING) to GEM_VERSION instead? Seems more accurate, inclusive of what the constant represents. Answer: Rename to DATADOG_GEM_VERSION.
• What should the behavior of datadog/auto_instrument be? Currently activates profiling and tracing automatically. Should this file be the "auto activate whatever is in the lib" trigger? (a.k.a more inclusive of just tracing/profiling?) Answer: It should instrument "everything" as it does today.
• Should we rename the ddtracerb bin? This file's sole purpose is to codelessly activate profiling, when used to wrap a Ruby process from shell. Should to be renamed to ddprofrb to reflect its actual behavior? Answer: Yes, to ddprofrb. Remove ddtracerb in its own PR.
• Should we rename the Faraday middleware named ddtrace to datadog? This middleware is trace specific. If renamed to datadog, and CI or ASM also want to add their own middleware, its name is ambiguous. Answer: Will update to datadog_tracing.
• There are a bunch of comments that were updated in transport code that suggest changing require_relative paths to ddtrace: paths which no longer exist. Not sure how to update these appropriately. (cc @ekump ) Answer: Conflict appears obsolete now.
• Should profiling artifacts/constants be updated to reflect datadog instead of ddtrace? There are a lot of direct references to the package name in the C code. I think this is a straight find-replace operation. (cc @AlexJF @ivoanjo ) Answer: Yes, but these are internals, and can be changed at any time. Stretch goal to change these in a separate PR.

[ekump]

Looks fine at first glance for non-profiling changes.

[ivoanjo]

👍 This seems reasonable to me!

My two main concerns are:

a. Smooth ddprofrb migration path
b. Changes to profiling stuff makes it hard to move stuff between master and 2.0 branch

And actually I think we can solve both a. and b. by moving most of the profiling changes to the master branch (e.g. as a separate PR).

Starting with a., we could introduce a bin/ddprofrb, side-by-side with the old bin/ddtracerb. The old ddtracerb would print a deprecation warning when getting used, and so customers on the latest 1.x would be able to move to the new name even before moving to 2.0, and would not be "surprised" when it's gone in 2.0. Then in the 2.0 branch we can remove it.

In the case of b., almost all of the changes to profiling (name of the extensions, build_ddtrace_profiling_native_extension script, etc) are internal things that are not part of any public API, so by making those changes in the master branch we'd simplify back/forward porting AND also make this PR a lot simpler as well.

Thoughts?

[ivoanjo]

Mike kindly asked to be given credit for helping out in getting us the datadog gem back, so I would suggest keeping this around :)

[ivoanjo]

I guess these dd-trace-rb paths should be updated too

[delner]

Technically these reflect the repo name; we can change these now (say to datadog-rb) if we want, but it would be out of step with the current repo name. I recommend holding off and doing repo renaming changes separately.

[delner]

@ivoanjo I'm onboard with your plan. I think we were hoping to do another 1.x release to add deprecation warnings anyways, so introducing the new ddprofrb there would fit well. Then we can open a separate PR that removes ddtracerb on the 2.0 branch.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.07%. Comparing base (344441e) to head (cd9d31c).

Additional details and impacted files

@@           Coverage Diff           @@
##              2.0    #3490   +/-   ##
=======================================
  Coverage   98.07%   98.07%           
=======================================
  Files        1237     1237           
  Lines       72254    72254           
  Branches     3408     3408           
=======================================
+ Hits        70863    70864    +1     
+ Misses       1391     1390    -1     

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

[delner]

Rebased this branch on the latest 2.0 and added one more name change of TRACER_VERSION to GEM_DATADOG_VERSION. All changes should be complete, just need a passing build now.

Handing off to @TonyCTHsu and @marcotc for any relevant system tests, benchmarks, etc...

[urseberry]

Documentation updates look good.