GRIB2 files that MET cannot decode
==================================

These two records exercise the error handling added for
[#3525](https://github.com/dtcenter/MET/issues/3525), where MET used to
segfault instead of reporting that the external g2c library could not decode a
record.

Each was made from the single `TMP`/`P500` GRIB2 record of
`model_data/grib2/sref_mn/sref_mean_2012040821_F003.grib2` in the unit test
input data, by overwriting one two-octet template number with a value that is
not defined in any version of the g2c library. The field is a temperature
rather than a wind component so that a non-zero exit status can only mean the
record failed to decode, and never that wind rotation failed for want of a
companion component. Nothing else was changed, so the
section lengths and the `7777` terminator remain valid and the files only fail
where they are meant to.

| File | Patched field | Value | What it exercises |
|---|---|---|---|
| `undefined_drt.grib2` | Section 5, octets 10-11, Data Representation Template number | 99 (was 40) | `g2_getfld()` fails at Section 5 and returns status 12. MET names the Data Representation Template it cannot unpack. |
| `undefined_gdt.grib2` | Section 3, octets 13-14, Grid Definition Template number | 999 (was 30) | `g2_getfld()` fails at Section 3 and returns status 10. MET names the Grid Definition Template it cannot handle. |

In both cases the record is skipped rather than added to the record list, so
each file ends up with no usable records and the tool exits 1. MET reports the
template at `Debug(2)`, which prints at the default verbosity, and the message
that stops execution is the existing one from the data file factory. Reading
`undefined_drt.grib2` at the default verbosity produces:

```
getdrstemplate: DRS Template 5.99 not defined.
DEBUG 2: MetGrib2DataFile::read_grib2_record() -> the external GRIB2 library failed to
         decode record at offset 0, field number 1, of GRIB2 file '...'
         (g2_getfld status = 12), packed with Data Representation Template 5.99 which
         this MET build's GRIB2 library cannot unpack.
DEBUG 2: MetGrib2DataFile::read_grib2_record_list() - skipped 1 of 1 GRIB2 record(s)
         that could not be decoded in file: ... Run with -v 4 to list them all.
WARNING: GRIB2 records not found in input file '...'
ERROR  : Met2dDataFileFactory::new_met_2d_data_file() -> error opening file "..."
```

`undefined_gdt.grib2` produces the same shape, with `getgridtemplate: GDT
Template 3.999 not defined.` and `(g2_getfld status = 10), on Grid Definition
Template 3.999.` in place of the Section 5 lines.

Note that the final `WARNING` reports no records were found. That is the honest
summary of an empty record list, but it is less precise than the real
diagnosis, which is the `Debug(2)` line above it. An earlier revision of #3525
kept a Section 5 failure in the record list so that MET could report that it had
found the requested field and then explain why it could not read it, which reads
better. That approach was removed because it required reading the `gribfield`
after a failed `g2_getfld()` call, and the library does not leave the caller a
field that is safe to touch on an error return.

Because no release of g2c defines either template number, both files fail the
same way whatever version of the library MET was linked against, and whether or
not it was built with CCSDS/AEC support.

To regenerate a file, parse the sections of a GRIB2 message, walk to the section
in question and overwrite the two octets named above. The real defect in #3525
was first reproduced with a genuine CCSDS-packed record, Data Representation
Template 5.42, against a g2c built without libaec. That file is not used here,
because a g2c built with libaec decodes it correctly and the test would not fail
on a build where everything is working.