One time database shrink catch-22 solution?
Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...


Why Does the Transaction Log Keep Growing or Run Out of Space?
Sql Server - Best Practices for Growing Database Files
SHRINKFILE best practices and experience
I Need to Shrink My Database - I just freed a lot of space
Reducing the size of a database
When is it OK to shrink a Database?
Database running out of space