Restore state of trigger based template binary sensor

[emontnemery]

Breaking change

Trigger based template binary sensors now initialized to the last state, instead of to "unknown".

Proposed change

Restore state of trigger based template binary sensor:

• If the stored state is "unknown" or "unavailable", it's not restored
• If the trigger binary_sensor has auto_off configured, the timer is restarted
  • If stored state is on but the timer has already expired when restoring the state, state is set to on

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes State of event-based template binary sensor shouldn't be unknown after HA restart #67397
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @PhracturedBlue, @tetienne, @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (template) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[emontnemery]

Maybe we should only restore state if either of CONF_AUTO_OFF; CONF_DELAY_ON; CONF_DELAY_OFF are set?

[mdegat01]

IMO restart/reload should not change the state of a trigger entity, only the trigger should. So they all should restore state to ensure that they always remain in whatever state was determined by the last trigger until the next trigger.

I am fine with adding a config option to control this behavior though in case there are cases I'm not considering where not restoring state is desirable. I don't know if I agree that the auto_off, delay_on and delay_off options make them more restorable. If anything auto_off sensors are the only ones that we could maybe skip restoring and just default to off for the reasons suggested by the author in the linked issue. But I think what you're doing here with restoring both the state and the timer sounds much better, I really like it.