I would say that overall you are correct in understanding of NFS. Here are some details about the points that you mentioned:
An NFSv3 server only provides the file ownership and access permissions. It's up to the client to enforce those permissions for specific users (i.e. when a process with a specific UID is requesting and fs operation).
Even if you setup NFSv4 with encryption, Kerberos authorization, and LDAP (and Krb and LDAP servers are running of a different host) then the client's root will still have the potential for at least as much fs privileges as all the allowed users and groups. But you could get protection again non-root user activity and even other hosts on the private network.
Normally clients will be very successful at enforce the user permissions. I'm not aware of any simple method to have the file permission ignores for an NFS mount. If that's what you want then simply set the permissions to u=rwx,g=rwx,o=rwx
for all folders and u=rw,g=rw,o=rw
for all files.
Off topic:
But be careful not to flip the setuid bit - that can actually end-up giving a root shell to regular users (e.g. www-data) on your client. Setuid can be disable completely with the "-o nosuid" option for NFS and non-NFS mounts.
There is a way to disable/enable rootsquash for the Solaris sever (it's called something other than rootsquash in the Solaris terminology - I forgot what it was).
You can have the Solaris server mark the entire share as read only, e.g.:
zfs set sharenfs="[email protected]/16" tank/home/tabriz
Then no matter what the client does, the fs will not be writable.
It's probably not possible for a non-root user on your client to open a direct connection to the NFS server even if the the program can talk the NFS protocol. This is because the NFS client is usually forced to connect form privileged ports and on healthy clients only root can do that.