Drop support for application keys

[Mr0grog]

Every so often folks run into trouble by mixing up API and application keys. Back in #118, I added more documentation and error messaging to help clarify potential issues, but I also noticed that the application keys don’t actually seem to be needed.

I did some testing and it turns out they definitely are not needed for submitting metrics, distributions, events, or logs (we don’t do the last two, but there is an open issue about supporting events). As far as I can tell, there’s no way for Datadog users to tell what application key something was submitted with, so they really don’t seem to have any value at all for our current use cases. Given the narrow goals of this library, we probably don’t ever want to support more complicated stuff that we would need application keys for, either.

Support was originally added by @gert-fresh back in 2015/2016 in PR #7. There’s not much description there, but I think it was because this library used to configure a single, globally available Datadog client, so a developer using this library might also want to use that client to do other things requiring an application key. That’s no longer how things work here today (each reporter instance has its own client, and those clients are not available to user code). Assuming I understand that correctly, the original use case is obsolete.

⚠️ Removing this feature is actually more work than keeping it (see code for handling different numbers of arguments and logging deprecations), but I want to remove it because its existence encourages users to include an unnecessary credential in their apps, which increases their security risks. Maybe it’s not worth worrying about, though?

---

Total side note: I haven’t touched this package in a while, but a few recent issues brought my attention back to it, so I thought I’d do some work on old issues and ideas that have been kicking around here. I figure I’ll work on a bunch of updates that might deprecate some things (like this, or #125) in the next week or so, and then cut another release at the start of next year that actually removes all the deprecations and cleans things out. Maybe we require a more recent version of Node.js then, too, so we can update some of our dev tooling (much of which has moved on to requiring Node.js 18+, which we only require 12+ here).

[Mr0grog]

Rebased to merge cleanly on top of main.