* at this point it would be nice to have a common base template for
  notifications for the greeting, footer, etc.

* return the request/record IDs for which reminders will be sent out, to
  enable simpler asserts in the tests
* handle the case that request topic's PID cannot be resolved - this is
  likely when the topic has not been published yet
* include "today" in the "accepted review" reminder, as too new requests
  will be filtered out anyway and are not expected to add significant
  load

* it looks like these fields in the name entry records got turned into
  strings at some point in our TISS sync, causing issues during
  marshmallow serialization

* to make SonarQube happy

* communities are created by administrators on request

* what we actually want to do is `removeprefix()` and `removesuffix()`

* this is quite a bit simpler than cobbling together the message in a
  normal python function

* whenever somebody other than the record owner publishes an edit for a
  record, the owner gets a notification with a summary of the changes
* if the owner publishes the edit themselves, then no such mail will be
  sent out - same for the system identity
* shared links with "edit" permissions still require a login to access
  the deposit form anyway, so edits are always backed by users

* by temporarily overriding the `notification.type`

* because it's very easy to get lost in the code without explanation

* so that reviewers know that somebody has started looking at the record
  and can remove it from their (mental) TODO list

* the "metadata" service component copies over every field *except for*
  "version" and "publication_date" from the old record

* missing version fields are handled by the UIJSONSerializer by
  constructing a string of the shape "v{version_index}"
* the "metadata" service component removes both the "version" and
  "publication_date" fields from new versions of records
* experience shows that users rarely put in explicit values for the
  version field, which creates inconsistency

* with the new rdm-curation workflow, community-submission requests
  cannot be used to circumvent our mandatory reviews anymore
* also, they have been requested as a feature

* previously, this property was missing from the fake entity which would
  trip up notification builders

* setting an empty value in the settings form previously caused a
  validation error because the empty string is not a valid email address

* previously, i forgot to override that configuration item after
  calculating its value
* if not set as configuration explicitly, Invenio-RDM-Records would then
  set a default value of "127.0.0.1:5000" for it

* because Invenio-App-RDM sets a default value for that config item
  mismatching our setup

* Invenio-Config already takes care of checking the value in real
  Invenio applications and issues a warning if it's unset

* `tuw_config` is a bit nicer than `zzz_invenio_config_tuw`, and should
  still be the last entry in the list considering the usual naming
  scheme

* previously, our configuration magic was performed as part of the
  `finalize_app` entrypoint
* while this worked well enough for most use cases, some extensions
  would break this model by caching values during their initialization
* especially caching-related extensions like to take eagerly create
  clients with the current configuration items, which are hard to fix
  afterwards
* keeping track of all the instantiated clients just to change their
  connection details when we perform our magic really didn't seem like
  a good approach
* so instead, we now made sure that our extension is loaded first and
  can thus perform its configuration magic before any other extension
  has a chance of caching values
* also, extension loading happens after the configuration loading is
  done (especially the handling of environment variables)

* since we're not quite ready for matrix notifications yet, this wasn't
  supposed to be added to the code

* add functionality to assemble some config items (like the DB
  connection string) from their parts
* this was previously implemented in our `invenio.cfg`, but more flaky
  because it had to deal with parsing and setting environment variables
* also refactor the startup module

* sometimes the cleanup operations for failed file uploads seem to leave
  over some `FileInstance` entries in the database that have a null URI
* these file instances cause the periodic health checks to fail and
  trigger warning emails

* this enables users to set an alternative email address to which
  notifications will be sent, in case they don't like to use their
  institutional email address

* this can be very useful for having a single project that is used for
  both "local" and "containerized" execution, where some configuration
  items should be slightly different for either (e.g. `SEARCH_HOSTS`)
* currently we have this functionality implemented in our `invenio.cfg`
  but there it is a bit awkward due to the fact that environment
  variables have not been translated into `app.config` yet

* this brings it more in line with the request notifications
* previously we were restricted to emails, now it will be whatever
  notification backends we use
* also remove the mail templates - they now live in code until we
  enhance the notification backend to be more flexible w.r.t. the
  rendered templates