Add publicly accessible units

[jen-w]

Issue #, if available:
N/A

Description of changes:
Having .now() in utils is nice. As a developer using this package, it would be also great to have publicly accessible constants for metric units available. It not only reduces the chance of silly spelling mistakes, but benefits discoverability outside of the documentation.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jaredcnance]

Thanks for the PR! Can we namespace (e.g. Units.SECONDS) these rather than dropping them in as constants?

[jen-w]

The most pythonic way that comes to mind to namespace is moving these constants to a new file called units.py. Happy to implement this in the next revision or any alternative preferred. Please let me know, thanks!

[Dunedan]

Another option would be use an Enum for the units. That'd have the advantage to play nicely with typing.

[jaredcnance]

I agree—I think that an enum is the preferred option here. This is what we do in the node and java libraries.

https://github.com/awslabs/aws-embedded-metrics-node/blob/master/src/logger/Unit.ts#L16

https://github.com/awslabs/aws-embedded-metrics-java/blob/master/src/main/java/software/amazon/cloudwatchlogs/emf/model/Unit.java#L21

[jen-w]

The thing I didn't really like with enum is that we'd access the string with something like Units.SECONDS.value, but I'm okay with that given the packages you linked use enum for units for consistency. One more question before I submit the next revision - should I create a new file, unit.py?

[jaredcnance]

is that we'd access the string with something like Units.SECONDS.value

I think for this version that should be okay. In the next breaking version we may choose to replace the signature of put_metric with the new enum type. Any strong disagreements with that approach?

should I create a new file, unit.py

Yes, I think that's a good choice and then we can add it as a top-level import.