Add TiledLogs to log list JSON

[mcpherrinm]

This adds the new TiledLog field to the loglist3 JSON.

It does it in what I think is a minimal backwards-compatible fashion, but which results in duplicating most of the Log struct. As this is a fairly "low level" representation of the log JSON, I think that's an appropriate choice.

There's some other options this could take, so I'd like to hear from the maintainers about how they'd like to proceed here.

We could add the new SubmissionURL and Monitoring URL fields to the existing log struct, and one or the other URLs will be set. Users of this code will have to know how to handle an empty URL, which they probably don't do today.

We could pull all the shared fields into a new "BaseLog" struct, which is embedded in both the TiledLog and Log structs. I think this is a decent option, but is a breaking change.

In any of these situations, I'd like to also update the FindLogBy* methods (or add a new version of each) to support both log types, at least for the shared submission paths which are common between both. That'll require some common representation - perhaps an interface with methods that correctly handle the differences. Supporting reading from a tiled log would be great for this package but is definitely beyond the scope of what I intend to accomplish right now.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[mcpherrinm]

force-pushed to change commit email so CLA check passes

[roger2hk]

/gcbrun

[phbnf]

The approach in this PR makes sense to me. Maybe highlight in the TiledLog docstring what the differences are?

Going over the other suggestions:

• We could add the new SubmissionURL and Monitoring URL fields to the existing log struct: +1 about what you say for the empty URL field. We could arbitrarily chose to put the Submission or Monitoring URL in there, but that would add yet more confusion I think.
• We could pull all the shared fields into a new "BaseLog" struct, which is embedded in both the TiledLog and Log structs. I think this is a decent option, but is a breaking change.: indeed... I think it's reasonable.

I'd like to also update the FindLogBy* methods (or add a new version of each) to support both log types: I think that adding a new version of the methods is preferable. The FindLogBy* methods return a Log object, so something like FindStaticLogBy* could return a TiledLog. It also matches nicely with the JSON schema. Having two sets of methods is not the most practical thing to use, but I think it's the best path forward for now to avoid breaking older clients, especially clients who use read endpoints, unless you can think of a different way?

[mcpherrinm]

OK, so I think we can go with this current approach, and adding new FindLogBy* methods.

I'd rather add those in a follow-up PR than this one, just since I want the new struct in a downstream project :), and will want to think through the FindLogBy* methods a bit, and make sure they work.

I will push another commit adding to the Log / TiledLog structs with some commentary contrasting them

[phbnf]

/gcbrun

[phbnf]

/gcbrun

[phbnf]

Thanks Matthew!