So, the usage of HTMLCacheUpdateJob would require the pageId, nsId and title dbkey of the title on the remote wiki to be known when constructed.
The LocalJobSubmitJob is run on a single wiktionary and fires CacheUpdateJobs out to the other wikis.
This means that we can not make a HTMLCacheUpdateJob directly within the LocalJobSubmitJob as we do not know the pageid of the page on the other wiki.

1. Do a lookup of the pageid on the remote wiki within our LocalJobSubmitJob, this seems a bit ugly :/
2. Keep our CacheUpdateJob (maybe rename it) and make this submit another HTMLCacheUpdateJob. This means there is an extra job in the chain :/
   1. Keep our CacheUpdateJob and call the construct and run the HTMLCacheUpdateJob from within!
3. CacheUpdateJob update the page_touched field? This doesn't solve what was mentioned in the review ticket regarding ease of forward compat with core caching
4. Extend HTMLCacheUpdateJob and override the run method and constructor. This would allow us to pass in the title that we know and do the pageid lookup later in the job.
5. Change HTMLCacheUpdateJob to be able to purge titles without requiring the pageid

2.A seems about right..

Change 334055 had a related patch set uploaded (by Addshore):
Use HTMLCacheUpdateJob internally

https://gerrit.wikimedia.org/r/334055

Change 334055 merged by jenkins-bot:
Use HTMLCacheUpdateJob internally

https://gerrit.wikimedia.org/r/334055