There’s a list of installation methods here: Set up a local Discourse Development Environment?. I have a non-Docker development site (using the Ubuntu guide). If it’s possible for you to do, I think you’ll get the best results with the non-Docker approach. One of the reasons I use it is to not have to deal with networking issues for API requests between Discourse and other applications that I’m developing locally. It’s faster than Docker too.
It should be. Make sure that the application that you’re generating the SSO payload on isn’t converting the boolean value true to 1. That’s a common problem. To get around it, you can set any boolean values in the SSO payload to the strings "true" or "false". Discourse will interpret them correctly. Check that first to see if it’s the issue. It could be something else. The code that handles avatar_force_update is kind of complex, but readable: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.
Edit: For the issue of boolean values in the SSO payload, I guess it’s more accurate to say that in the process of generating the SSO payload, the environment is going to convert the boolean values true/false to strings. Discourse is expecting the strings to be "true" or "false", other programming environments may deal with them differently. For example:
PHP:
wp> strval(true)
=> string(1) "1"
as opposed to Ruby:
irb(main):001> true.to_s
=> "true"
Python (I’m not sure how Discourse handles this one):
>>> str(True)
'True'