It is critical. It is a candidate key. It should be the number that the provider sends to you to identify which number the upstream caller used.
Yes, although most people will use 0.0.0.0, unless they specifically want to restrict the interface. That’s generally what is done with IP networking applications, normally they bind to 0.0.0.0, often without any other option being obvious,
Providing you are using chan_pjsip, the most secure is with both off. For chan_sip there are cases where the only realistic option is to have them on.
Depends on both your provider and the exact sort of account you have with them. For consumer grade providers, you typically want transport UDP, registration outbound, and authentication outbound. For more upmarket ones you may have transport TLS, registration none, authentication none.
If the provider sends the DID value in the request URI, and in the form you want, context should be from-pstn (or is that from_pstn) or from-trunk, which I believe are handled the same. There are standard contexts for the case where the ID is in the To: header, and there is one that canonicalises North American numbers. For more complex cases, you may need to provide your own context and dialplan.
All providers will require the server IP, and will also require the server port if that isn’t the default.
See above. You will also need to provide user name and password, if authenticating. You are likely to need to provide caller IDs in acceptable formats for outbound routes and you may need settings for how caller IDs are handled. I have no knowledge of DIDWW, and, as I pointed out above, provides may have more than one account type. I’m also approaching this from the point of having used Asterisk in anger, and not FreePBX, so I may have got some names wrong or missed some options.