Simplify the constructors for PeriodicBatchingSink and BoundedConcurrentQueue.

[oliverholliday]

The current way that the constructors are implemented prevents some types of configuration and sub-classes of PeriodicBatchingSink have two paths of constructor logic. This PR aims to simplify and improve this.

The motivation was needing to extend PeriodicBatchingSink and pass in all configuration as follows:

public EventHubSink(EventHubClient client, EventHubLogSinkConfiguration config)
    : base(config.BatchSizeLimit, config.BatchPeriod, config.BatchQueueLimit)
{
   _client = client;
}

Additionally I've added a RootNamespace declaration to fix warnings about incorrect namespaces.

[nblumhardt]

Hi! Thanks for the PR. The BoundedConcurrentQueue changes look good. We can't change the signature of the protected PeriodicBatchingSink constructor, though, as existing assemblies dependent on it will fail to bind without a rebuild.

[oliverholliday]

How about the new update, where the original constructors are maintained but a new one added.

This has the added benefit that a call to the original constructor specifying the queueLimit now doesn't create a queue with no limit, then immediately replace it with one that has a limit.

[nblumhardt]

Hi Oliver - sorry about the delay! I'll take a look at this ASAP 👍

[nblumhardt]

Okay, back in action!

I think the implementation of the PeriodicBatchingSink constructors is cleaner in this PR - it's great that there's only the one flow of control, now, and no create-then-replace process for the queue, as you point out 👍

I am mildly unsure of the three constructors now being exposed to subclasses, especially the two three-argument versions where the only difference is in the nullability of the third int argument. It's not really feasible to obsolete the non-nullable version, since the compiler will bind it when an int is supplied, in preference over the int? version, even if we [Obsolete()] the old constructor.

I still lean toward making the change, but is there another way we can clean up the constructor list that I'm not considering, @serilog/reviewers-core? I.e. are there more arguments to PeriodicBatchingSink..ctor() that we could include in a new overload, so that there's no ambiguity which is being chosen, and so we can get the most bang for our buck out of this change?