message: style: clarify the wording around likely/unlikely environment errors.
  * style: clarify the wording around likely/unlikely environment errors.
  Align the wording with the intent and practice around when it's fine to RELEASE_ASSERT.
diff: A few general notes on our error handling philosophy:
  * All error code returns should be checked.
  -* At a very high level, our philosophy is that errors that are *likely* to happen should be
  - gracefully handled. Examples of likely errors include any type of network error, disk IO error,
  - bad data returned by an API call, bad data read from runtime files, etc. Errors that are
  - *unlikely* to happen should lead to process death, under the assumption that the additional burden
  - of defensive coding and testing is not an effective use of time for an error that should not happen
  - given proper system setup. Examples of these types of errors include not being able to open the shared
  - memory region, an invalid initial JSON config read from disk, system calls that should not fail
  - assuming correct parameters (which should be validated via tests), etc. Examples of system calls
  - that should not fail when passed valid parameters include most usages of `setsockopt()`,
  - `getsockopt()`, the kernel returning a valid `sockaddr` after a successful call to `accept()`,
  - `pthread_create()`, `pthread_join()`, etc.
  +* At a very high level, our philosophy is that errors should be handled gracefully when caused by:
  + - Untrusted network traffic OR
  + - Raised by the Envoy process environment and are *likely* to happen
  +* Examples of likely environnmental errors include any type of network error, disk IO error, bad
  + data returned by an API call, bad data read from runtime files, etc. Errors in the Envoy
  + environment that are *unlikely* to happen after process initialization, should lead to process
  + death, under the assumption that the additional burden of defensive coding and testing is not an
  + effective use of time for an error that should not happen given proper system setup. Examples of
  + these types of errors include not being able to open the shared memory region, system calls that
  + should not fail assuming correct parameters (which should be validated via tests), etc. Examples
  + of system calls that should not fail when passed valid parameters include the kernel returning a
  + valid `sockaddr` after a successful call to `accept()`, `pthread_create()`, `pthread_join()`, etc.
  * OOM events (both memory and FDs) are considered fatal crashing errors. An OOM error should never
  silently be ignored and should crash the process either via the C++ allocation error exception, an
  explicit `RELEASE_ASSERT` following a third party library call, or an obvious crash on a subsequent
  