What you describe just sounds like a standard HTTP to HTTPS (and non-www to www) redirect, so it's not clear why the webhost's directives failed in the way you suggest.
However, since you would expect each /joomlasite to have its own .htaccess file that also contains mod_rewrite directives then this could well complicate matters. Although, if anything, you would expect these subdirectories to not redirect at all. (See below.)
To redirect HTTP to HTTPS and non-www to www then try the following near the top of the .htaccess file in the root of your site:
RewriteEngine On
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=302,L]
Make sure you clear your browser cache before testing.
This also assumes the SSL cert is installed on your server and you are not using an SSL front-end proxy to manage your SSL.
Note that this is a 302 temporary redirect. Only change it to a 301 permanent redirect when you are sure it's working OK. 301s are cached hard by the browser, so can make testing problematic.
UPDATE: If you wanted a more generic solution that doesn't involve hardcoding the domain then you can do something like the following instead:
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)\.?$ [NC]
RewriteRule ^ https://www.%1%{REQUEST_URI} [R=302,L]
This is very similar to the above, except with an additional RewriteCond directive, which is required in order to capture the domain apex from the Host header.
A generic solution isn't necessarily the "best solution". (Although it might be.) In the infinite world of varying server configs, hardcoding the domain name is often going to be the most reliable solution.
However, this may not do anything for the subdirectories that contain their own .htaccess files (if these files also contain mod_rewrite directives). If this is the case then you will either need to repeat the above directives in each subdirectory's .htaccess file, or enable mod_rewrite inheritance by either placing the following directive in each subdirectory's .htaccess file:
RewriteOptions InheritBefore
Or, on Apache 2.4.8+, you can instead include the following directive in just the root .htaccess file:
RewriteOptions InheritDownBefore
But whether the mod_rewrite inheritance is successful without modifying existing directives is dependent on what other directives you have in the parent .htaccess file.
mod_rewrite inheritance is not trivial. Directives are literally copied in-place. So, if you have per-directory directives that are dependent on the relative file-path then these can break. (This is primarily why I have used REQUEST_URI in the directive above, rather than capturing the URL-path from the RewriteRule pattern.) So, the easiest solution - without knowing more about your system - may be to simply copy the redirect directives (above) into each sub .htaccess file.
UPDATE:
This is the rule they put in:
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
If these directives were used in the .htaccess file in the document root of your site and mod_rewrite inheritance was also enabled (as described above), then this would indeed exhibit the behaviour you were seeing, ie. everything in /joomlasite is redirected to the root. eg. http://www.example.com/joomlasite/foo would get redirected to https://www.example.com/foo in the root - the /joomlasite directory is effectively "lost".
This is because the inherited directives are copied in-place (as mentioned above). If these directives are run in the context of the .htaccess file in the /joomlasite subdirectory then the URL-path captured by the RewriteRule pattern (and later used in the $1 backreference) would be foo, not joomlasite/foo, because the directory-prefix (of where the .htaccess file is located) is first removed from the URL-path. This then results in a substitution of the form https://www.example.com/foo.
However, the directives I posted earlier, that use REQUEST_URI instead of $1, get around this issue since REQUEST_URI always contains the full URL-path of the request.
