Q:

elasticsearch file descriptors and vm warnings become errors when not binding to localhost?

For those landing on this post trying to resolve these errors for yourself (whereas I'm only asking about what they mean), I have provided my steps at the bottom of this post for getting rid of the errors.

Installed elasticsearch and can access from localhost, but having timeout issues when trying to connect from remote machine. Trying to fix throws error that before trying to fix, were just warnings. 
This other post (Installed elastic search on server but cannot connect to it if from another machine) may be outdated as when inspecting elasticsearch.yml, there appears to be no network.bind_host variable and the post seems to be referring to an older version. But following it as much as possible, running 
[me@mapr07 config]$ netstat -ntlp | awk '/[j]ava/'
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)          
tcp6       0      0 127.0.0.1:9200          :::*                    LISTEN      21109/java          
tcp6       0      0 ::1:9200                :::*                    LISTEN      21109/java  

shows that we are binding to localhost and "if you are binding to localhost (i.e. 127.0.0.1), you can only accept connections from the localhost, not over the network."(https://stackoverflow.com/a/24057311/8236733) (I don't know much networking stuff).
From the elasticsearch docs (https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html#advanced-network-settings), tried setting the network.bind_host variable in $ES_HOME/config/elasticsearch.yml to 0.0.0.0 (like in the original post). However, after rersterting elasticsearch, we see the output:
[2018-05-15T14:49:54,395][INFO ][o.e.n.Node               ] [TjtCCG8] starting ...
[2018-05-15T14:49:54,603][INFO ][o.e.t.TransportService   ] [TjtCCG8] publish_address {127.0.0.1:9300}, bound_addresses {[::]:9300}
[2018-05-15T14:49:54,620][INFO ][o.e.b.BootstrapChecks    ] [TjtCCG8] bound or publishing to a non-loopback address, enforcing bootstrap checks

ERROR: [2] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

[2018-05-15T14:49:54,641][INFO ][o.e.n.Node               ] [TjtCCG8] stopping ...
[2018-05-15T14:49:54,670][INFO ][o.e.n.Node               ] [TjtCCG8] stopped
[2018-05-15T14:49:54,670][INFO ][o.e.n.Node               ] [TjtCCG8] closing ...
[2018-05-15T14:49:54,701][INFO ][o.e.n.Node               ] [TjtCCG8] closed

I don't get how this happens and I also don't get why it is even a real problem, since it previously threw this error as a warning when bound to localhost and would run anyway, eg.
[2018-05-15T15:01:32,017][INFO ][o.e.n.Node               ] [TjtCCG8] starting ...
[2018-05-15T15:01:32,283][INFO ][o.e.t.TransportService   ] [TjtCCG8] publish_address {127.0.0.1:9300}, bound_addresses {[::1]:9300}, {127.0.0.1:9300}

[2018-05-15T15:01:32,303][WARN ][o.e.b.BootstrapChecks    ] [TjtCCG8] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
[2018-05-15T15:01:32,304][WARN ][o.e.b.BootstrapChecks    ] [TjtCCG8] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

[2018-05-15T15:01:35,372][INFO ][o.e.c.s.MasterService    ] [TjtCCG8] zen-disco-elected-as-master ([0] nodes joined), reason: new_master {TjtCCG8}{TjtCCG8LQOWOE2HNFdcLxA}{ik_q1XYnTk-BBJXcBMNK_A}{127.0.0.1}{127.0.0.1:9300}

My question is, why does this happen? In both cases there appears to be the same number of file descriptors and vm space being used, so why is it that when binding to 0.0.0.0 that amount is no longer just a warning level but an error?
For those landing on this post trying to resolve these errors for yourself (whereas I'm only asking about what they mean), I have provided my steps below for getting rid of the errors.

Doing some quick googling, the docs advise running the command 
sudo su  
ulimit -n 65536 
su elasticsearch (dont exit *back* to elasticsearch session, since new limit only applies to current session (which ends if you exit))

to address the max file descriptors [4096] for elasticsearch process is too low error, since

Elasticsearch uses a lot of file descriptors or file handles. Running
  out of file descriptors can be disastrous and will most probably lead
  to data loss. Make sure to increase the limit on the number of open
  files descriptors for the user running Elasticsearch to 65,536 or
  higher.

(https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html#file-descriptors). Secondly, to address the max virtual memory error, run
(sudo) sysctl -w vm.max_map_count=262144

on linux systems, since 

The default operating system limits on mmap counts is likely to be
  too low, which may result in out of memory exceptions

(https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html#vm-max-map-count).

A:

Since elasticsearch when bootstrap, it will check the bind address whether is loopback address(127.0.0.1), if it is a loopback address it will ignore the bootstrap check errors.
Reference:
BootstrapChecks.enforceLimits

