user metadata fields are absent for reference and sample data

Overview: The fields metadata.createdByUserId and metadata.updatedByUserId are not present for reference data or sample data values (e.g. /coursereserves/coursetypes, /groups, /acquisistions-units/units, /instance-formats, etc).

How to reproduce:

Invoke POST /_/tenant with neither X-Okapi-User-Id nor X-Okapi-Token header.

This is the code that fills the metadata property: https://github.com/folio-org/raml-module-builder/blob/v33.2.7/domain-models-runtime/src/main/java/org/folio/rest/tools/utils/MetadataUtil.java#L33-L55

It creates a metadata property like this:

"metadata": {
  "createdDate": "2022-03-15T10:34:03.966",
  "updatedDate": "2022-03-15T10:34:03.966+00:00"
} 

How to fix:

Invoke POST /_/tenant with X-Okapi-User-Id header, for example "X-Okapi-User-Id: 715d1d4b-0709-4e71-9066-761ce19674b9", or with a valid token with a user id.

Then MetadataUtil creates a metadata property like this:

"metadata": {
  "createdDate": "2022-03-15T10:34:03.966",
  "updatedDate": "2022-03-15T10:34:03.966+00:00",
  "createdByUserId": "715d1d4b-0709-4e71-9066-761ce19674b9",
  "updatedByUserId": "715d1d4b-0709-4e71-9066-761ce19674b9"
}

This works for all examples listed above (tested against master branch on March 15, 2022):

• /coursereserves/coursetypes (mod-courses)
• /groups (mod-users)
• /acquisistions-units/units (mod-orders-storage)
• /instance-formats (mod-inventory-storage)

Note that mod-users might not be enabled for the tenant at that time.

Background:

I don't remember it working this way before, but this also reproduces in folio-juniper and folio-kiwi, which suggests it did work this way before and I just didn't notice. It also reproduces on bugfest (BF-244), an environment that is built very differently (data are migrated from previous FOLIO releases, rather than reference and sample data being installed fresh).

In any case, there is an expectation among librarians viewing the UI that reference data will have these metadata fields populated, but they aren't and Prokopvych (the module owners) don't understand why. Maybe it's a problem with how the module stores these values or sends them to Okapi (a problem for the module owners) or maybe RMB has changed its expectations (a problem for the RMB owners) or maybe the system's assumptions about these data during setup and migration are incorrect (a problem for ref-env and bugfest devops teams).