
  -spec spawn_request(Node, Module, Function, Args, Options) -> ReqId
                         when
                             Node :: node(),
                             Module :: module(),
                             Function :: atom(),
                             Args :: [term()],
                             Options :: [Option],
                             Option ::
                                 monitor |
                                 {monitor, [monitor_option()]} |
                                 link |
                                 {reply_tag, ReplyTag} |
                                 {reply, Reply} |
                                 OtherOption,
                             ReplyTag :: term(),
                             Reply :: yes | no | error_only | success_only,
                             OtherOption :: term(),
                             ReqId :: reference().

Since:
  OTP 23.0

  Asynchronously send a spawn request. Returns a request identifier 
  ReqId.

  If the spawn operation succeeds, a new process is created on the
  node identified by Node. When a spawn operation succeeds, the
  caller will by default be sent a message on the form {ReplyTag,
  ReqId, ok, Pid} where Pid is the process identifier of the
  newly created process. Such a message is referred to as a success
  message below in the text. ReplyTag is by default the atom 
  spawn_reply unless modified by the {reply_tag, ReplyTag}
  option. The new process is started by the application of 
  Module:Function to Args.

  The spawn operation fails either if creation of a new process
  failed or if the spawn operation was interrupted by a connection
  failure. When a spawn operation fails, the caller will by default
  be sent a message on the form {ReplyTag, ReqId, error, Reason}
  where Reason is the error reason. Such a message is referred to
  as an error message below in the text. Currently the following
  spawn error Reasons are defined, but other reasons can appear at
  any time without prior notice:

  badopt:
    An invalid Option was passed as argument. Note that
    different runtime systems may support different options.

  notsup:
    The node identified by Node does not support spawn
    operations issued by spawn_request().

  noconnection:
    Failure to set up a connection to the node identified by Node
    or the connection to that node was lost during the spawn
    operation. In the case the connection was lost, a process may
    or may not have been created.

  system_limit:
    Could not create a new process due to that some system limit
    was reached. Typically the process table was full.

  Valid Options:

  monitor:
    In the absence of spawn operation failures, atomically sets up
    a monitor to the newly created process. That is, as if the
    calling process had called monitor(process, Pid) where Pid
    is the process identifier of the newly created process. The 
    ReqId returned by spawn_request() is also used as monitor
    reference as if it was returned from monitor(process, Pid).

    The monitor will not be activated for the calling process
    until the spawn operation has succeeded. The monitor can not
    be demonitored before the operation has succeeded. A 'DOWN'
    message for the corresponding monitor is guaranteed not to be
    delivered before a success message that corresponds to the
    spawn operation. If the spawn operation fails, no 'DOWN'
    message will be delivered.

    If the connection between the nodes involved in the spawn
    operation is lost during the spawn operation, the spawn
    operation will fail with an error reason of noconnection. A
    new process may or may not have been created.

  {monitor, MonitorOpts}:
    In the absence of spawn operation failures, atomically sets up
    a monitor to the newly created process. That is, as if the
    calling process had called monitor(process, Pid, MonitorOpts)
    where Pid is the process identifier of the newly created
    process. See the monitor option above for more information.

    Note that the monitor will not be activated for the calling
    process until the spawn operation has succeeded. For example,
    in the case that an alias is created using the monitor option,
    the alias will not be active until the monitor is activated.

  link:
    In absence of spawn operation failures, atomically sets up a
    link between the calling process and the newly created
    process. That is, as if the calling process had called 
    link(Pid) where Pid is the process identifier of the newly
    created process.

    The link will not be activated for the calling process until
    the spawn operation has succeeded. The link can not be removed
    before the operation has succeeded. An exit signal due to the
    link is guaranteed not to be delivered before a success
    message that corresponds to the spawn operation. If the spawn
    operation fails, no exit signal due to the link will be
    delivered to the caller of spawn_request().

    If the connection between the nodes involved in the spawn
    operation is lost during the spawn operation, the spawn
    operation will fail with an error reason of noconnection. A
    new process may or may not have been created. If it has been
    created, it will be delivered an exit signal with an exit
    reason of noconnection.

  {reply, Reply}:
    Valid Reply values:

    yes:
      A spawn reply message will be sent to the caller
      regardless of whether the operation succeeds or not. If
      the call to spawn_request() returns without raising an
      exception and the reply option is set to yes, the
      caller is guaranteed to be delivered either a success
      message or an error message. The reply option is by
      default set to yes.

    no:
      No spawn reply message will be sent to the caller when the
      spawn operation completes. This regardless of whether the
      operation succeeds or not.

    error_only:
      No spawn reply message will be sent to the caller if the
      spawn operation succeeds, but an error message will be
      sent to the caller if the operation fails.

    success_only:
      No spawn reply message will be sent to the caller if the
      spawn operation fails, but a success message will be
      sent to the caller if the operation succeeds.

  {reply_tag, ReplyTag}:
    Sets the reply tag to ReplyTag in the reply message. That
    is, in the success or error message that is sent to the
    caller due to the spawn operation. The default reply tag is
    the atom spawn_reply.

  OtherOption:
    Other valid options depends on what options are supported by
    the node identified by Node. A description of other valid 
    Options for the local node of current OTP version can be
    found in the documentation of spawn_opt/4.

  This function will fail with a badarg exception if:

   • Node is not an atom.

   • Module is not an atom.

   • Function is not an atom.

   • Args is not a proper list of terms.

   • Options is not a proper list of terms.

  Note that not all individual Options are checked when the spawn
  request is sent. Some Options can only be checked on reception
  of the request. Therefore an invalid option does not cause a 
  badarg exception, but will cause the spawn operation to fail with
  an error reason of badopt.

  A spawn request can be abandoned by calling 
  spawn_request_abandon/1.
