Invalid Timezone Sent in LTI Launch When User's Profile Set to Server Default

For users whose timezone is set to use the server default timezone, when they launch an LTI resource link, an invalid timezone code of 99 is sent rather than the server timezone default.

However, if the user changes the timezone in their profile to something other than the server default (even if they select the same timezone as the server default), the LTI launch includes a valid timezone (in this example "America/New_York")

Replication steps

1. Create two local sites - one called consumer, the other called provider. Set up the sites according to the Moodle LTI docs - one as the consumer site and one as the provider.
2. Publish something from the provider - a course module is fine - using LTI 1.1
3. Make sure the consumer can launch into the published content as per normal LTI usage (read the docs if you're unsure)
4. On the consumer site, set up a new external tool instance in a course, using the following custom params (click "Show more" under "General" on the mod edit form to see custom params):
   • timezone=$Person.address.timezone
5. Make sure the user's timezone is set to server default (admin user should have this set by default but worth checking anyway)
6. Launch the tool
7. Inspect the launch data via a breakpoint in the launch code  - just check the value of $requestparams here: https://github.com/moodle/moodle/blob/9dc2ee548df71cbfc46286804d17968a35d8d53e/mod/lti/locallib.php#L681 - you'll see that the substitution param custom_timezone is set.
   Expected: It's set to a real value, e.g. "Australia/Perth".
   Actual: It's set erroneously to "99", which is the placeholder for server default.

Note: This will also affect LTI 1.3 launches as the same substitution params are supported there afaik.

Possible solution

This code in lti_get_capabilities(): https://github.com/moodle/moodle/blob/9dc2ee548df71cbfc46286804d17968a35d8d53e/mod/lti/locallib.php#L3855 defines the substitution value as the value from the $USER global ($USER->timezone), whereas it should allow us to stipulate something more akin to:

core_date::get_user_timezone($USER); 

to make sure 99 is resolved to the respective server time.

The function lti_parse_custom_parameter() is responsible for taking that $USER->timezone string (as defined in lti_get_capabilities - as above), and resolving it to a real value. That method will probably also need some work to resolve this properly. Right now, I don't believe there is a means to resolve a method call- That only supports '->' syntax but we might want to do something like that to solve this problem with timezone properly.