Slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do). Whether that's designed on purpose (doubts) or is actually buggy remains to be seen.
Should there be no such effect the requested functionally could be provided without any new option.
To add more, init-slave is around to fine tune slave appliers so @@SESSION level setting
like this one could be technically done though that.

What do you mean "slave appliers indeed ignore global.max_statement_time which they must be initialized with (as the user connection threads do)" ? Every THD gets max_statement_time, slave thread too. It's copied from global in plugin_thdvar_init() which is called from THD::init(). What slave threads don't do — they don't set the query timer to expire after max_statement_time seconds. In THD::set_query_timer() slave threads are explicitly excluded. This looks very much like on purpose, one can hardly write slave_thread || unintentionally.

I don't think it's a good idea. If the slave thread would always be using global.max_statement_time — that's one thing. But if you're adding an option anyway, better to have an option like --slave-max-statement-time and not --slave-uses-global-max-statement-time

Hi Andrei!

This is ready for review.

https://github.com/MariaDB/server/pull/2182

Completed the work. The final review was provided by Sergei (kudos for pretty constructive notes and heads-ups!).

The adopted solution was to add a new variable, Slave_max_statement_time, which can be
used to limit the time that slave is going to wait for a query to be executed.
The slave will no honor max_statement_time.