Add a CloudWatchRecorder builder

[MasonHM]

The builder allows passing in a ScheduledExecutorService for additional
control over metric publishing execution.

This replaces pull request #5 by allowing the customer to inject exception handling if they need it.

[MasonHM]

Example ScheduledExecutorService to wrap the Runnable so that it will catch exceptions, log them, and then survive:

    public class LogAndDropScheduledThreadPoolExecutor extends ScheduledThreadPoolExecutor {
        private ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor();

        public LogAndDropScheduledThreadPoolExecutor() {
            this(1);
        }

        public LogAndDropScheduledThreadPoolExecutor(int corePoolSize) {
            super(corePoolSize);
        }

        @Override
        public void execute(Runnable command) {
            executorService.execute(() -> {
                try {
                    command.run();
                } catch (Throwable t) {
                    // log and do nothing
                    log.error("Problem encountered during Runnable execution", t);
                }
            });
        }

        @Override
        public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
                long initialDelay,
                long period,
                TimeUnit unit) {
            return executorService.scheduleAtFixedRate(() -> {
                try {
                    command.run();
                } catch (Throwable t) {
                    // log and do nothing
                    log.error("Problem encountered during Runnable execution", t);
                }
            }, initialDelay, period, unit);
        }
    }

Example ScheduledExecutorService to log exceptions after execution and then die:

    public class LogAndDieScheduledThreadPoolExecutor extends ScheduledThreadPoolExecutor {

        public LogAndDieScheduledThreadPoolExecutor() {
            this(1);
        }

        public LogAndDieScheduledThreadPoolExecutor(int corePoolSize) {
            super(corePoolSize);
        }

        @Override
        protected void afterExecute(Runnable r, Throwable t) {
            super.afterExecute(r, t);
            if (t == null && r instanceof Future<?>) {
                try {
                    Object result = ((Future<?>) r).get();
                } catch (CancellationException ce) {
                    t = ce;
                } catch (ExecutionException ee) {
                    t = ee.getCause();
                } catch (InterruptedException ie) {
                    Thread.currentThread().interrupt(); // ignore/reset
                }
            }
            if (t != null) {
                log.error("Problem encountered during Runnable execution. Shutting down executor", t);
            }
        }
    }

[bradboswell]

Do we need to deprecate these constructors?

While I agree that some customers will prefer the builder I also think some may prefer the constructors as well. Maintaining both can present some challenges (e.g. keeping defaults in sync) but as library vendors I'm not sure this is somewhere we need to be opinionated about how someone uses our library.

[MasonHM]

No, they don't need to be deprecated. They would be phased out in the ideal case, but I'm not in a position to drive the deprecation campaign, so I'm fine with leaving them as-is and adding the builder.

[bradboswell]

In the same vein does this need to be private? Potential cost of it being public is?

Builder does no null or error checking, so I don't think exposing this increases the risk that customers will use this in error.

[MasonHM]

Similar to my other comment, if we're going to support both constructors and the builder moving forward, this can be made public.

[bradboswell]

It's weird that this doesn't use a builder? The remaining constructors do.