Certificate_list which is described in RFC 5246 as: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list and each following certificate MUST directly certify the certificate preceding it.
Because Certificate Validation requires that root keys be distributed independently, the Self-signed Certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
The server would send the Certificate_list in the ServerHello and the Client would send the Certificate_list only after receiving the CertificateRequest.
If a client wants to exempt your site from Certificate Validation, they SHOULD NOT add your Root Certificate to Certificate Trust Store. More than likely that user is not aware that they open door to nearly all their SSL connections (except pinned ones). They should only ever trust your Site Certificate (aka the leaf certificate).
Technically, the only bad thing that can be told about sending the Root Certificate in the Certificate Chain is that it uses a bit of network bandwidth needlessly. That's about 1 kB data per connection which includes a Full TLS Handshake. In a typical session between a client (Web browser) and a server, only one connection will be of that type as the other connections from the client will use "Abbreviated TLS Handshake" which build on the initial handshake, and do not use certificates at all. And each connection will be kept alive for many successive HTTP requests. So the network overhead implied by the placing the Root Certificate in the certificate_list is slight.
Additionally the popular test site ssllabs.com test site issues a minor warning in case a root is concatenated, describing the connection with something like "contains anchor".