I’ll take each of your requirements in turn:
/run is restricted by snapd. To save data you need to write it to $SNAP_DATA or $SNAP_COMMON, although as daemons are handled by systemd you probably don’t need a pidfile.
Again, this location is restricted by snapd. Logging of daemons in the snap world is handled via ssystemd and journald.
This is another location restricted by snapd. You should try to use either $SNAP_DATA or $SNAP_COMMON for this data.
Snapd confinement blocks access to /etc. Your configuration data should be saved in $SNAP_DATA.
Like above for /var/log this is anticipated to be handled by systemd and journald. (Write your daemon’s logging output to STDOUT and STDERR.)
Currently all daemons are run as root, but work is underway to allow snaps to specify dropped-privileges via a user-account: Multiple users and groups in snaps
There is a capability to run a script on initial installation, but this script will be run in the same confinement as your snap will run, and thus cannot alter the system outside of the snap’s restricted execution domain.
I believe you can do this with the process-control interface/plug such as via something akin to the following snapcraft.yaml snippet:
apps:
my-daemon:
command: usr/bin/my-daemon
daemon: simple
plugs:
...
process-control
...
Shared memory is allowed but must conform to a strict naming regime for the device files in /dev/shm. The snap will be unable to access shared memory from other programs that aren’t packaged within the same snap.
Snapd imposes no limits on the amount of memory a snap may utilise.
Once you have applied the network-bind interface/plug then you may listen on any arbitrary port provided, similarly to unconfined applications, that no other program has the same port bound at the time you attempt to open it.
You cannot install these outside of your snap. You can expose commands which point to these codes and scripts, which will be included within the system’s PATH environment variable by default, but cannot apply scripting into the user’s bash profile because snapd confinement prevents access to $HOME without the home plug/interface and even with that interface dotfiles are excluded meaning you cannot modify $HOME/.bashrc or $HOME/.bash_profile.
A lot of effort has been applied to get snaps suitable for both server applications and client applications. In both cases there are restrictions on the manner in which the application can operate when confined, but if you really cannot cope you can still use classic mode, however you may not be able to distribute it via the store: Classic mode requires a manual review by the store admins and may be rejected, unless there is a strong reason for distributing in classic mode.
Ideally all snap packages should have some attempt put into working within the confinement ecosystem as this is the safest for our users.