Add Service Metadata To Every DMR

[ndp-opendap]

Let us consider the pros and cons of adding service metadata to every DMR (metadata or dap4 data response) that hyrax produces.

• Allows changes to the server's output and behavior to be addressed by client talking to the server or looking at a cached DMR or DAP4 Data response.

Ideas scratch pad (Hack it up)

    <Attribute name="service_metadata" type="Container">
        <Attribute name="server" type="String">
            <Value>hyrax</Value>
        </Attribute>
        <Attribute name="version" type="String">
            <Value>1.17.1-2553-test-deploy</Value>
        </Attribute>

Here's an organization more like what we used in the build_dmrpp_metadata block

    <Attribute name="service_metadata" type="Container">
        <Attribute name="hyrax" type="String">
            <Value>1.17.1-2553-test-deploy</Value>
        </Attribute>
        <Attribute name="bes" type="String">
            <Value>3.20.13<</Value>
        </Attribute>
        <Attribute name="libdap" type="String">
            <Value>3.20.11</Value>
        </Attribute>

[ndp-opendap]

☝️ @Mikejmnez ☝️ @jgallagher59701 ☝️ @hannahilea ☝️

[hannahilea]

I like this idea a lot.

In terms of implementation, will we break any downstream responses/testing when we add this? I can imagine users currently running diff tests on generated dmr, and those diff tests breaking when we add this---which might mean we should do a (hyrax?) version bump (minor or major, not patch) if we add this.

[ndp-opendap]

Yes - this will break many tests, ours and others I am sure.

About a release number change, and this by no means a "no we wouldn't", but: Bumping the version number from 1.17.1 to 1.17.2 would, if we stick by our release principles, mean that we are making an actual official release. Which is about a week of effort. (I have on one occasion done it in 3 days, but it's been more than a year since the last official release so there is a bunch to do.)

And we are woefully overdue for a full release.