Sean Massey-1

So...this is a problem.  As a consultant supporting this environment, you need to understand the use cases and usage patterns.  The details are very important, especially when the use case or usage pattern raises an architectural issue like you're experiencing.  It is hard to provide recommendations or a solution if you don't know why some users need a session that runs for 2 days to complete a process or the impact that is has on operating the environment.
You have to go back to your customer to gather these details.
This is going to be hard to do within one pool. But I will provide some options below.
So this is where understanding the customer's use case and the task are really important.  Perhaps this specific task or process could me moved to an RDSH server, automated in some way so it doesn't rely on the desktop, or if none of that is possible, moved into a desktop pool dedicated to this task (ie - users would only log into that desktop to run this specific workflow...or these users would be moved into a pool with different settings so they can run this task without issue).  But without details, you can't provide alternatives.
You can't extend a session unless the user signs in or remains active.  Once they disconnect, the timer starts, and the only way to stop it is to reconnect.
You might be able to end a disconnected session early using DEM.  I have not tested this, so it's only a concept.  You would need to test this in your lab before presenting it to your customer.  But the idea would be as follows:
1. Set the pool log off after disconnect timer to 2880 minutes (which you've already done)
2. Set up a policy in DEM to run a Task on Disconnect for users who are not in the group of AD Users who the longer sessions.  This task would enable a scheduled task to log out the user after 2 hours from when the task runs.  This would have to be done with a PowerShell script that would modify and enable a scheduled task.
3. Set up a policy in DEM to run a Task on Reconnect for users who are in the AD user group to disable the scheduled task if they reconnect to their session.  This would prevent the scheduled task from running and logging them out if they rejoin their session.
Another option would be to use the Horizon REST API to get all the disconnected sessions that are over 2 hours old, check each session's users against the group of users who need longer sessions, and log out those that do not. This is probably the option I would recommend because it doesn't rely on multiple steps inside of a desktop, but it would require you or the customer to write the tool to do this.  I'm not aware of any application or tool that does this today.

There is definitely something going on with that connection server that is causing issues without taking the service offline.  Normally, when Horizon stops responding to requests, the entire web server component is offline, so favicon.ico fails.
Have you opened a support ticket to investigate the issue that is causing the server to fail?  I would start there because this is not normal behavior.  
For now, I would recommend disabling the bad connection server inside your AVI pool so that no connection attempts are sent to it and open a ticket to investigate. 

Partially correct.  You would need 3 public IPs in total, but each UAG would need to have it's own unique Blast/Tunnel URL.
It would look something like this:
Floating/Shared VIP for UAG HA: 100.64.1.0/horizon.any_guy.com
UAG1 NAT Public IP: 100.64.1.1/horizon_uag1.any_guy.com
UAG2 NAT Public IP: 100.64.1.2/horizon_uag2.any_guy.com
Basically, yes.  Once you authenticate, you're communicating directly with the UAG that you authenticated against.  All session protocol/secondary traffic happens with that UAG, which is why each UAG needs to have its own DNS name/NAT public IP.
Partially.  In my experience, the UAG VIP will actually float between the two UAGs if both are up.  The authentication process will always remain available, and if one UAG goes down, the VIP will remain available on the UAGs that are online.
I'm not sure what you mean by this.  If a UAG goes down/fails, then user sessions that are connected to that UAG will be disconnected and the user will need to reconnect.  The UAG is basically a reverse proxy for Horizon, and session protocol/secondary protocol traffic is pinned to the UAG that the user authenticated against. 
This is only relevant if you're using a 3rd-party external load balancer like Netscaler, F5, AVI, or similar services.  UAG HA is outside of the scope of that document as stated in one of the opening paragraphs:
 
Yeah.  This happened because I did not configure my UAG HA prerequisites properly, and I didn't realize it at the time.
I used a single URL (horizon.lab.example) and VIP for both UAG1 and UAG2.  So what would happen is that a user would connect, and the VIP would be on UAG1.  So they would authenticate with UAG1 and their Blast session would go through UAG1.  But at some point during that user session, the VIP would float to UAG2.  And as soon as that happen, the user sessions would freeze and eventually disconnect.  Now this was in a lab environment, so it didn't cause any production impacts or outages, but it was still frustrating for myself and some other lab users.
That's why I say that you need to make sure you meet the prerequisites of N+1 public IP addresses and unique DNS names for each UAG because it won't work as intended without them.