Hi,
Yes you're dealing with the correct module.
You can see that in the XML:
<fields name="params" addfieldpath="/components/com_hikashop/fields">
<fieldset name="basic">
<field
name="moduleclass_sfx"
type="text"
label="COM_MODULES_FIELD_MODULECLASS_SFX_LABEL"
description="COM_MODULES_FIELD_MODULECLASS_SFX_DESC" />
</fieldset>
<fieldset name="hk_options" label="Hikashop Options">
<field
id="hikashopmodule"
name="hikashopmodule"
multiple="true"
type="hikashopmodule"
label="HikaShop"
description="HikaShop options"
/>
</fieldset>
</fields>
Which means that there is an option of the type hikashopmodule in the module. That is a custom type which doesn't exists in Joomla by default and as the XML says, you can find custom option types in the folder /components/com_hikashop/fields
So there, you can open the file hikashopmodule.php and you'll see that it's loading the file 'options' of the view 'modules' with this line:
$content = hikashop_getLayout($layout,'options',$params,$js,true);
And if you look for that view file via the menu Display>Views, you'll find that this view file contains all the options of a HikaShop content module.
Why not directly having the options in the XML ? Because doing it the way we do allows for much more flexibility for us. We can have our own design for the options tab, we can have advanced options with complex dependencies with other options (which wouldn't be possible with Joomla), third party extensions can add their own options dynamically to the view (like HikaMarket does), and the view can even be overridden by the marchants if necessary.