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...
- http://dba.stackexchange.com/questions/29829/why-does-the-transaction-log-keep-growing-or-run-out-of-spaceWhy Does the Transaction Log Keep Growing or Run Out of Space?
- http://dba.stackexchange.com/questions/23305/sql-server-best-practices-for-growing-database-filesSql Server - Best Practices for Growing Database Files
- http://dba.stackexchange.com/questions/47310/shrinkfile-best-practices-and-experienceSHRINKFILE best practices and experience
- http://dba.stackexchange.com/questions/53857/i-need-to-shrink-my-database-i-just-freed-a-lot-of-spaceI Need to Shrink My Database - I just freed a lot of space
- http://dba.stackexchange.com/questions/30824/reducing-the-size-of-a-databaseReducing the size of a database
- http://dba.stackexchange.com/questions/17277/when-is-it-ok-to-shrink-a-databaseWhen is it OK to shrink a Database?
- http://dba.stackexchange.com/questions/42539/database-running-out-of-spaceDatabase running out of space