9.2.x: invalid remap.config files are no longer FATAL

[bneradt]

While testing 9.2.x, I accidentally created an invalid remap.config file. In previous releases, ATS would fail to start if it loaded an invalid remap.config file and it would emit a FATAL log message. In 9.2.0 (not released yet), this is no longer the case: ATS starts, albeit with ERROR messages.

This change looks intentional per the following PR: #7782

However we might want to reconsider this because this is a pretty significant change in behavior that can lead to confusing 404 responses for the user. Consider the following possible scenario:

1. An admin creates a problematic remap.config entry near the end of the file, maybe 95% down.
2. They restart ATS. In 9.1, ATS would refuse to come up with a FATAL message. In 9.2, it now emits an ERROR but does start with the previous remap entries active in its running state.
3. Since the majority of the remap.config entries were parsed, their smoke testing shows that the remap.config file seems to work. Remapping works fine in general, and unless they test entries at or after their corrupted remap.config entry, remapping will seem to work.
4. This runs in prod for a while and the diags.log file is rotated.
5. The admin gets reports about unexpected 404 errors due to the few entries near the bottom of the remap.config file.

In this situation, he does not see diags.log errors anymore because they only happened after ATS restart. The corruption in the remap.config may not be obvious. In fact, particular entries may be fine with their only problem being that they come after the corrupted entry, which may be many lines before that for which the current 404 responses correspond. Thus for large remap.config files (ours are thousands of lines long), a corrupted entry may be almost impossible to detect visually.

Perhaps it's preferable for reloads to be more lenient, while keeping initial remap.config loading strict?

[randall]

I'm +1 on fixing this.

[randall]

If someone wants it to soft fail on startup, it should be opt in (like the ssl_multicert.config var https://docs.trafficserver.apache.org/admin-guide/files/records.config.en.html?highlight=proxy%20config%20ssl%20server%20multicert%20exit_on_load_fail#proxy-config-ssl-server-multicert-exit-on-load-fail)

[ezelkow1]

+1 on a soft fail option if the way it is working now is desired. For us we definitely would prefer the old behavior of hard fail on startup. Half-soft fail on bad reload where it continues using the old remap without killing ATS until it can do a full valid reload of the config file

[randall]

Ditto with everything @ezelkow1 said.