Should entry metadata be stored on the logger, or passed explicity?

[tseaver]

The entries.write API takes a number of optional, non-payload variables for each entry:

• resource is a MonitoredResource: AFAICT, we should always be passing it as {"type": "global"} (the others are generated by the various API backends).
• labels is an arbitrary key-value mapping (distinct from the structPayload).
• severity is an enumerated value, defaulting to LogSeverity.DEFAULT.
• insertId for de-duplication (set by the backend if not passed).
• httpRequest is a struct describing the HTTP request associated with the entry.
• operation is a struct allowing multiple entries to be grouped into an "operation".

resource and labels can also be passed as top-level defaults.

My question is: how should we expose these options? Should we capture values on the logger itself (e.g., when constructing it)? Should we allow passing them as explicit arguments to the individual log_text/log_struct calls? Some of them should clearly be per-entry (httpRequest, insertId, severity). operation might map best onto a batch-like entity (see #1565). labels and resource (assuming we allow it) seem like they are better associated with the logger.

[jgeewax]

Can we do an inherit-down model? Where we define things that may want to be shared on the logger, and the methods inside can override that default?

[tseaver]

operation now tracked as #1676. Other features added in #1668, #1669.